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

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

 



On Tue, Feb 11, 2025 at 1:56 AM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote:
[snip]
> > > On Wed, Feb 5, 2025 at 2:14 PM D. Ben Knoble
> > > <ben.knoble+github@xxxxxxxxx> 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 :)





[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