Re: [PATCH v7 1/1] pull: add ff-only option

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

 



On Mon Nov 23, 2020 at 7:08 PM EST, Felipe Contreras wrote:
> I'd have no objection in refactoring this option so it's used for
> both, but this breaks existing behavior. A user that has
> "pull.ff=only", and does a "git pull --rebase" might expect it to
> work.
>
> My main interest is what happens when the user has not configured
> anything, which I defined with a "push.mode=default", any option (e.g.
> --rebase/--merge) would override that default.

I feel like the parsimonious change to make is simply defaulting the
existing "pull.ff" to "only". I think someone who has set "pull.rebase"
expects pull --rebase behavior just as much as someone who passes
--rebase on the command line. The issue in question is what someone who
has not made any changes to the settings expects to happen with a plain
"git pull", and I certainly agree that people who are not power users
expect a fast-forward (I try not to force my opinions on workflow or
style when onboarding people to Git, but I do always recommend
"pull.ff=only" because I know this is a perennial pitfall).

The problem is that, as it stands now, this would just leave the user
with a cryptic error message ("Not possible to fast-forward, aborting")
when they wanted to see remote changes. I think this might warrant an
even more expanded message than the short one in this patch, but I'm
not sure exactly what it should say - there are a few things the user
might expect, but an error message isn't the best place for a crash
course.




[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