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

Re: [PATCH] pull: allow branch.<name>.rebase to override pull.ff=only

From
D. Ben Knoble <ben.knoble+github@gmail.com>
Date
Feb 10, 2025, 20:26 UTC
Message-ID
<CALnO6CDZ=rq_eZESzi++VFk081ddosHMpKQV4QHNFJbnsOMAzg@mail.gmail.com>
In-Reply-To
<CAMMLpeQvJUZJuwvK-H=M_FFedpgazGOPH=7wvPCg3U8RrxEtkA@mail.gmail.com>
On Thu, Feb 6, 2025 at 9:36 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
Show 19 quoted lines
>
> On Tue, Feb 4, 2025 at 8:11 PM D. Ben Knoble
> <ben.knoble+github@gmail.com> wrote:
> >
> > When running "git pull" with the following configuration options, we
> > fail to merge divergent branches:
> >
> > - pull.ff=only
> > - pull.rebase (unset)
> > - branch.<current_branch>.rebase=true
> >
> > Yet it seems that the user intended to make rebase the default for the
> > current branch while using --ff-only for non-rebase pulls.
>
> You make an interesting point. The idea is that more specific options
> override less specific options. In this case, "fast-forward only" is
> more specific than "rebase" (because rebasing might or might not
> fast-forward), but "my branch" is also more specific than "all
> branches". So which option should win? 🤔

Precisely! I think "my branch" is most specific here, but Junio's argument is (if I understand it) that pull.ff=only is _stronger_, regardless of specificity.

Show 16 quoted lines
>
> On Wed, Feb 5, 2025 at 2:14 PM D. Ben Knoble
> <ben.knoble+github@gmail.com> wrote:
>
> > Is there, then, an existing combination that means roughly to treat
> > `git pull` with no other options like this:
> > - if not rebasing, forbid merging and be equivalent to --ff-only
> > - if rebasing is requested (because of branch.name.rebase or --rebase
> > or …?), allow it
>
> I think what we're missing is a branch.<name>.ffOnly option to make a
> particular branch fast-forward only. Such an option would be
> especially useful for the master branch, but you could set it on all
> of your branches except the ones that you want to rebase. We could
> even have a branch.autoSetupFfOnly option to turn on ffOnly
> automatically for new branches.

That is probably something that is missing, and might solve the problem, but I don't know that these in particular are something I need (read: want to implement).

How do you (and Junio, and others) feel about pull.ff=onlyUnlessOverridden? The meaning would be "like --ff-only except when branch.<name>.rebase says otherwise."

The name of the value can be workshopped (I initially thought of "override" as a short value, but it may be too short to convey its intended meaning). Perhaps "onlyOr[Branch]Rebase"?

I think this would be a smaller change that meets my needs without changing the meaning of ff=only.

>
> -Alex
Previous: Alex HenrieNext: Alex Henrie
Message 7 of 13 in “pull: allow branch.<name>.rebase to override pull.ff=only”
  1. pull: allow branch.<name>.rebase to override pull.ff=onlyD. Ben Knoble, Feb 5, 2025
  2. Junio C HamanoFeb 5, 2025
  3. D. Ben KnobleFeb 5, 2025
  4. Junio C HamanoFeb 5, 2025
  5. D. Ben KnobleFeb 5, 2025
  6. Alex HenrieFeb 7, 2025
  7. D. Ben KnobleFeb 10, 2025
  8. Alex HenrieFeb 11, 2025
  9. D. Ben KnobleApr 22, 2025
  10. D. Ben KnobleApr 22, 2025
  11. D. Ben KnobleApr 22, 2025
  12. D. Ben KnobleApr 22, 2025
  13. Junio C HamanoApr 22, 2025

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.