Re: [RFC] git-brebase

From: Alejandro Colomar <alx@kernel.org>
Date: Oct 3, 2026, 20:56 UTC
Message-ID: <asFoq4gnl1caJM2U@debian>
In-Reply-To: <asFoDZKscLKqaIf+@ubby>

Hi Nico,

> Date: 2026-10-03 15:39:41-0500
> From: Nico Williams <nico@cryptonector.com>
>

[...]

Show 7 quoted lines

> > It might be confusing to have these three flags being dependent on
> > another flag, and not being able to use this within a git-bisect(1)
> 
> IMO that's not a problem at all.  There are a lot of Unix/Linux commands
> that have flags that only make sense when used with other specific
> flags.  So I still like a `--first-conflict` or `--onto-first-conflict`
> option.

Yeah, it could make sense.  I'm not sure, but it could be.

> (I really like `--pre-exec` and `--post-exec`, BTW.)

:)

Show 9 quoted lines

> > session, unlike other git-rebase(1) operations.  That might call for
> > a new git command.
> 
> That might still be the case in that this will be such a useful tool
> that it deserves a name.  But also, `git-rebase(1)` should always have
> been this useful, so that argues for this to be either... a new option
> like `--onto-first-conflict`, or even a new default behavior.
> 
> Does jj have a feature like this?  What do they call it?

No idea.

[...]

Show 8 quoted lines

> > while test $# -ge 1; do
> 
> I normally use
> 
>   while getopts +:<short-options-here> opt; do ...
> 
> I also have a getopts_long-like function (see my gists) for bash if you
> like.

I think getopts(1) is not usable for git(1)-related scripts, because getopts(1) interprets '--' as the end of the options, but git(1) uses it for distinguishing commits from paths. If anyone shows me how it can be used, I'd be interested, because I've hit this issue in the past with other script.

Show 7 quoted lines

> > [...]
> > 
> > # Set up the callback script for 'git rebase run'.
> > mktemp \
> > | read -r callback;
> 
> I like to set a `trap` to remove temp files.

Hmmm, makes sense. If so, I'll also try to filter out the line that prints the name of the command, since 'git bisect run' prints it, and we don't want users to try to open a file that doens't exist.

Show 8 quoted lines

> > cat >"$callback" <<__EOF__
> > #!/bin/bash
> > ...
> > __EOF__
> > chmod +x "$callback";
> 
> Here what might be better is to have a command-line option to execute
> this callback without having to write it to a file,

How would you do it?

> and use environment
> variables to pass arguments to it.

The callback doesn't really need any arguments, since 'git bisect run' won't pass any arguments to it.

Show 9 quoted lines

> > # Perform the conflicting rebase
> > git switch "$branch";
> 
> Ah, that came from:
> 
> > git rev-parse --abbrev-ref HEAD \
> > | read -r branch;
> 
> which means I can't use this in detached HEAD mode :(

Oh!  I wasn't aware that git-rebase(1) supported detached HEAD mode.

> I work in detached HEAD mode almost exclusively.  I know, that's..
> weird.  But it works for me.

Ouch! Indeed. :) Out of curiosity, are there any interesting reasons for such self-implied pain?

> Can we avoid forcing the user to be on a
> branch?

I guess I could keep a variable that remembers the state of the HEAD across all the rebases. It should be doable. I'll have a look (maybe tomorrow).

Have a lovely night! Alex

> Nico
> --

-- 
<https://www.alejandro-colomar.es>