git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Pick the right default and stop warn on `git pull`

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Nov 26, 2020, 01:02 UTC
Message-ID
<CAMP44s0M00sBvdjD0jc0X=1=PJepC5fNndw73sceOpbDCw5dFQ@mail.gmail.com>
In-Reply-To
<xmqq7dqagtgx.fsf@gitster.c.googlers.com>
On Tue, Nov 24, 2020 at 6:39 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
>
> Alex Henrie <alexhenrie24@gmail.com> writes:
>
> > We'd only need a warning if both pull.ff and pull.rebase are unset,
> > since that's the only situation where the behavior would change. And
> > providentially, we already have a warning in that exact case, although
> > we should probably tweak it to explain what the new behavior is going
> > to be :-)
>
> If we were starting "git pull" from scratch without any existing
> configuration and command line options, pull.mode might present a
> simpler end user experience, but I have to say that pull.ff and
> pull.rebase that are fairly well ingrained in docs and users' minds,
> the above plan sounds like a better option to reduce the cognitive
> overhead for users.

Is it? From forums, blogs, and answers in Stack Overflow what I mostly see is "do not do git pull".

Show 10 quoted lines
> >> And yes, it should be possible to do what you suggest, but have you
> >> tried? I suspect both the code and the documentation would be quite
> >> convoluted.
> >
> > Yes, I have written a very simple patch that implements the behavior
> > that I am suggesting. I will send it to the mailing list later
> > tonight.
>
> Let's see how well the comparison between two approaches play out.
> Thanks.

I tried to remove pull.mode from my patch series, and it mostly works, except if you:

1. Have "pull.ff=only"
2. Do a "git pull --no-rebase"

When you have "pull.mode=ff-only", doing "git pull --no-rebase" ("git pull --merge") that mode is overridden, and the merge succeeds.

If you have "pull.ff=only", you would have to do "git pull --no-rebase --no-ff" for the merge to succeed, which I don't think should be the default.

We could change the semantics of "pull.ff=only", but that would break existing behavior, and it starts to get convoluted.

Cheers.
-- 
Felipe Contreras
Previous: Junio C HamanoNext: Junio C Hamano
Message 26 of 29 in “Pick the right default and stop warn on `git pull`”
  1. Vít OndruchNov 23, 2020
  2. Alex HenrieNov 23, 2020
  3. Theodore Y. Ts'oNov 23, 2020
  4. Felipe ContrerasNov 23, 2020
  5. Theodore Y. Ts'oNov 23, 2020
  6. Felipe ContrerasNov 23, 2020
  7. Jeff KingNov 23, 2020
  8. Alex HenrieNov 23, 2020
  9. Jeff KingNov 24, 2020
  10. Junio C HamanoNov 23, 2020
  11. Felipe ContrerasNov 23, 2020
  12. Jeff KingNov 24, 2020
  13. Felipe ContrerasNov 24, 2020
  14. Jeff KingNov 24, 2020
  15. Junio C HamanoNov 24, 2020
  16. Jeff KingNov 24, 2020
  17. Felipe ContrerasNov 24, 2020
  18. Jeff KingNov 24, 2020
  19. Felipe ContrerasNov 24, 2020
  20. Jeff KingNov 24, 2020
  21. Vít OndruchNov 24, 2020
  22. Alex HenrieNov 24, 2020
  23. Felipe ContrerasNov 24, 2020
  24. Alex HenrieNov 24, 2020
  25. Junio C HamanoNov 25, 2020
  26. Felipe ContrerasNov 26, 2020
  27. Junio C HamanoNov 23, 2020
  28. Felipe ContrerasNov 23, 2020
  29. Felipe ContrerasNov 23, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.