Re: A simple git workflow for the rest of us

[Bill Wohler]

Steinar Bang <address@hidden> writes:

>>>>>> Bill Wohler <address@hidden>:
>
>> I'd second setting it globally to ensure that it happens universally
>> to avoid the spurious merge commits that otherwise ensue.
>
> (I've never understood why "spurious merge commits" bother people so
> much. Personally I'm much more concerned with what might happen to my
> individual commits if I'm hitting a conflict during rebase: the commit's
> diff may no longer be the clear and meaningful diff I indented it to be)

Like many things, it depends.

If a merge in either direction doesn't add any information, it's
spurious. If it's useful, it's not spurious. For me, a merge commit from
a pull breaks up the flow of my unpushed commits and usually doesn't add
anything. I can imagine that folks used to Subversion would prefer
pull --rebase as well as that mimics svn update. Sort of.

If it's vital to capture that merge in the middle of your own commits,
then the pull should be merged. I've just never encountered this
situation. In the situation you presented, could you use git rebase
--abort and then run git merge origin/master to recover?

In any event, there is no right or wrong answer. It all depends.

p.s. Hey Steiner, long time no "see"!

-- 
Bill Wohler <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD