Re: Defaulting --rebase-merges overall?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tao Klerks <tao@xxxxxxxxxx> writes:

> 1. Change the "Need to specify how to reconcile divergent branches"
> pull conflict hint text to offer "git config pull.rebase merges"
> instead of "git config pull.rebase true"
> ...
> As I think about it, the global option sounds like it might be hard to
> prove the correctness of (and compatibility with the hosts of other
> options), so I probably won't be qualified to do this. Is there any
> objection to the simple hint change, at least?

I think suggesting "[pull] rebase = merges" is more in line with the
original spirit of suggesting "you want to recreate your work on top
of the updated upstream".

I do not particularly find it a good idea to suggest configuring
"git pull" to always rebase (whether it rebases with mergesor
flattens) in the first place, but if we were to offer such an option
anyway, "merges" is a much better choice than "true" to flatten,
simply because that matches the goal of "to recreate your work on
top of the updated upstream" better.

The only reason why 'true' is in the suggestion is because 'merges'
came much later than "when tried to pull and got a conflict, you'd
rebuild your work on top of theirs" suggestion was introduced.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux