Re: [RFC] git-brebase

> Date: 2026-10-03 22:56:32+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi Nico,
> 
> > Date: 2026-10-03 15:39:41-0500
> > From: Nico Williams <nico@cryptonector.com>
> >
> [...]
> > > 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.)
> 
> :)
> 
> > > 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.
> 
> [...]
> > > 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.
> 
> > > [...]
> > > 
> > > # 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.
> 
> > > 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.

> 
> > > # 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>