Re: A simple git workflow for the rest of us

[Sergey Organov]

Bill Wohler <address@hidden> writes:

> 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.

AFAIK, one can pull with merge, then finally, before pushing, call "git
rebase" by hand, and Git will get rid of all those intermediate merges
while rebasing. This doesn't play nicely with intended local merges. The
latter is unlikely to make any difference for simple workflows though.

One probably needs to enable "rerere" to avoid repeating the same merge
resolution.

-- 
Sergey.