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
Alex Henrie <alexhenrie24@gmail.com>
Date
Feb 11, 2025, 06:55 UTC
Message-ID
<CAMMLpeSgSTU+SVeU6A_9LJvjVbho+QC8HpNQtKJvFic98xKvJQ@mail.gmail.com>
In-Reply-To
<CALnO6CDZ=rq_eZESzi++VFk081ddosHMpKQV4QHNFJbnsOMAzg@mail.gmail.com>

On Mon, Feb 10, 2025 at 1:26 PM D. Ben Knoble <ben.knoble+github@gmail.com> wrote:

Show 25 quoted lines
>
> On Thu, Feb 6, 2025 at 9:36 PM Alex Henrie <alexhenrie24@gmail.com> wrote:
> >
> > 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.

I can see it both ways here, though in general when the user's intent is ambiguous, I think Git should default to the more conservative operation.

Show 30 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
Previous: D. Ben KnobleNext: D. Ben Knoble
Message 8 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.