Re: [RFC] git-brebase

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]