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
Apr 22, 2025, 20:03 UTC
Message-ID
<CALnO6CDb8_V9T3o+ON-8BZHcuf83UNGp23zxJKMc-rcGY=M1iA@mail.gmail.com>
In-Reply-To
<CAMMLpeSgSTU+SVeU6A_9LJvjVbho+QC8HpNQtKJvFic98xKvJQ@mail.gmail.com>

On Tue, Feb 11, 2025 at 1:56 AM Alex Henrie <alexhenrie24@gmail.com> wrote: [snip]

Show 54 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.
>
> In my opinion, the matrix of which pull options override which pull
> options is already too hard to understand. Rather than add a new
> dimension to pull.ff, I would much prefer to fill in the gap that is
> the lack of a per-branch fast-forward setting. It might be more work
> in the short term, but it's an investment:
> pull.ff=onlyUnlessOverridden would only address your particular use
> case, but a per-branch setting could address many others. For example,
> the user could set branch.autoSetupRebase=true to make every branch
> rebase by default, but override it with branch.master.ff=only to make
> the master branch fast-forward only. Or the user could have
> branch.<name>.rebase set to either true or false as appropriate for
> each branch, but temporarily set branch.<name>.ff=only when they are
> in the middle of work on a branch and don't want to accidentally bring
> in upstream changes that would interrupt their work.
>
> If you think that you can write the patch to implement
> pull.ff=onlyUnlessOverridden on your own, I think you're capable of
> implementing branch.<name>.ff=(true|false|only) and
> branch.autoSetupFf=(true|false|only). Use the code for the existing
> branch.<name>.rebase and branch.autoSetupRebase options as a guide,
> and people like me are available on the mailing list to support you.
>
> -Alex

I actually did start working on this by first writing documentation; I got about as far as saying that branch.<name>.rebase overrides branch.<name>.ff when pulling unless it is only and that branch.<name>.ff overrides merge.ff before I realized that I was constructing a complex decision-matrix of how config and CLI options affect what happens, and it's already overwhelming enough…

It would actually be nice to spell out the matrix somewhere, but I can do that in a blog post if I ever find time. I'll leave it to others to increase the complexity of that matrix :)

Previous: Alex HenrieNext: D. Ben Knoble
Message 9 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.