Re: Amending merge commits?

[Sergei Organov <osv@javad.com>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where their changes are small discrete patches in a
> clump on top of upstream.

I think they rather ask for avoiding tons of meaningless automatic
merges resulting from periodic pulling from upstream.

Those subset of the above who only do small discrete patches don't do
merges to their tracking branches, except by mistake, right? If so,
'pull --rebase=preserve' makes no difference compared to --rebase=true
to their normal workflow. Moreover,if someone merges something to his
tracking branch by mistake, how is it different from making merge to any
other branch by mistake? Just fix the mistake by resetting to previous
state.

On the other hand, if someone decides to merge something else to his
tracking branch by purpose, both --rebase=preserve and --rebase=false
perform as expected, while --rebase=true may easily lead to huge
surprise. Please refer also to this thread for one such case:

http://www.mail-archive.com/git%40vger.kernel.org/msg55605.html

> When someone has made a merge by mistake (with 'git pull' before
> remembering to do an autosetuprebase, or with 'git merge' instead of
> cherry-picking some patches they needed), the current --rebase=true
> behavior can be a good way of cleaning up.

Once again, in case of mistake they are free to use --rebase=true, and
even then using 'git rebase' directly is probably cleaner. That said, I
don't argue --rebase=true could be sometimes useful. It's just that I
think --rebase=preserve is safer, so it should be a good idea to suggest
to use it (in favor of --rebase=true) in general.

> That said, in some specific workflows, --rebase=preserve may work
> better than --rebase=true.

It does indeed, and I don't think my aforementioned workflow is too
specific.

> My hunch is that even those workflows are not currently handled well
> with --rebase=preserve, alas.

--rebase=preserve works fine for the aforementioned workflow. At least
simple tests I performed so far ran fine. I'd like to learn though which
nasty drawbacks --rebase=preserve has for tracking branches compared to
--rebase=true, if any.

> A clearer explanation of --rebase (maybe with sub-headings for each
> choice *true*, *false*, and *preserve*?) sounds useful.  An
> illustration in the EXAMPLES section of git-pull(1) of the difference
> between these three modes and when to use them would be even more
> helpful.

That would be an improvement anyway, indeed.

-- 
Sergey.