Re: fc/pull-merge-rebase, was Re: What's cooking in git.git (Dec 2020, #01; Tue, 8)

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

 



"Theodore Y. Ts'o" <tytso@xxxxxxx> writes:

> On Wed, Dec 09, 2020 at 01:28:48PM -0800, Junio C Hamano wrote:
>> 
>> A spot check: do you have pull.rebase set to anything in your
>> config?
>
> FWIW, I haven't set pull.rebase to anything, but what I have done is
> to simply added --ff-only or --rebase to my "git pull" commands.  I
> type fast, though, so it's not that a big deal, and I like the fact
> that the warning is making me explicitly express what it is that I
> want to have happen.

OK, so I would tone down my optimism that the loud warning we have
been issuing for a long time would be sufficient---the switching of
the default would break people like you.

> It's also true that very often, I end up running "git fetch", then
> look at what I got pulled down, and only then run either "git merge"
> or "git merge --ff-only" or "git rebase" explicitly.

That is very understandable.

"git pull", which is "git fetch" followed by some way to reconcile
two histories, does not have to be the only way to interact with
histories from other people.

It however doesn't give useful input to help us answer the questions
Johannes raised: is it sensible to force users to tell "git pull" if
they want to merge or to rebase explicitly, instead of defaulting to
merge like we currently do?  how much damage are we causing to
existing users who expect the command to work the way it currently
does?

Thanks.



[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