Cool, starting to make a little more sense. Do people use rebase or do
people skip it--in general and at square?


On Sat, Feb 15, 2014 at 1:35 PM, Shawn Morel <notifications@github.com>wrote:

> In gossip/infostore.go:
>
> > @@ -181,6 +181,39 @@ func (is *InfoStore) AddInfo(info *Info) bool {
> >  	return true
> >  }
> >
> > +// Visitor pattern to run two methods in the course of visiting all
>
> Uhg hard to explain from my phone and my laptop is out of power If you're
> the only person son aiming the branch rebasing is ok. But rebasing always
> rewrites history. Roughly, it reapplies the original patches in order on
> after the last commit you're naming (master in your case) At first, avoid
> git pull since it does an implicit merge. Just always do git fetch followed
> by git merge. Once you're used to things git pull is a useful shortcut but
> can still burn you. GitHub has a good description of both. Assuming no one
> else has done work on your topic branch your can git push -f. By default,
> git is preventing you from rewriting history in a remote / published branch
> I can give you a good run down at the office shawn
> ... <#14436d4d3c1c47d4_>
> Sent from my iPhone
>  On Feb 15, 2014, at 13:10, Spencer Kimballd <notifications@github.com>
> wrote: In gossip/infostore.go: > @@ -181,6 +181,39 @@ func (is *InfoStore)
> AddInfo(info *Info) bool { > return true > } > > +// Visitor pattern to run
> two methods in the course of visiting all Wow, I really just don't
> understand git. Is it generally a bad idea to try to rebase my branch after
> pulling master to get your lint changes? The rebase had conflicts as your
> lint change modified some things which were changed/deleted. I fixed those
> conflicts, added them and did git rebase --continue. Now if I try to push,
> I get: To https://github.com/spencerkimball/cockroach.git ! [rejected]
> spencerkimball/diff-filter -> spencerkimball/diff-filter (non-fast-forward)
> error: failed to push some refs to '
> https://github.com/spencerkimball/cockroach.git' hint: Updates were
> rejected because the tip of your current branch is behind hint: its remote
> counterpart. Integrate the remote changes (e.g. hint: 'git pull ...')
> before pushing again. hint: See the 'Note about fast-forwards' in 'git push
> --help' for details. It's not obvious from the git man page what (e.g. 'git
> pull ...') is supposed to actually mean in practice. -- Reply to this email
> directly or view it on GitHub.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/spencerkimball/cockroach/pull/4/files#r9773762>
> .
>