On Mon, Feb 10, 2025 at 1:26 PM D. Ben Knoble <ben.knoble+github@xxxxxxxxx> wrote: > > On Thu, Feb 6, 2025 at 9:36 PM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote: > > > > On Tue, Feb 4, 2025 at 8:11 PM D. Ben Knoble > > <ben.knoble+github@xxxxxxxxx> 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. > > 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
