From: Nico Williams <nico@cryptonector.com>
Date: Sat, 03 Oct 2026 20:39:41 GMT
Subject: Re: [RFC] git-brebase
Message-ID: <asFoDZKscLKqaIf+@ubby>
In-Reply-To: <asFRVdMTpshsazgM@debian>

On Sat, Oct 03, 2026 at 10:11:47PM +0200, Alejandro Colomar wrote:
> We'll discuss the exact way it should be integrated within git(1), but
> first it'd be interesting to get feedback about the tool itself,
> regardless of the actual form.  Actually, because of the specialized
> flags --pre-exec and --post-exec, and the --first-parent flag from
> git-bisect(1) --and the fact that it runs git-bisect(1) machinery--, I'm
> not entirely sure that it should be just a new flag to git-rebase(1).
> 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.

(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?

> ---
> #!/bin/bash
> # Copyright 2026, Alejandro Colomar <alx@kernel.org>
> # SPDX-License-Identifier: GPL-3.0-or-later
> 
> set -Eeufo pipefail;
> shopt -s lastpipe;
> 
> err()
> {
> 	>&2 printf '%s\n' "$(basename "$0"): error: $*";
> 	exit 1;
> }
> 
> fp='';
> other='';
> pre='';
> post='';
> 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.

> [...]
> 
> # Set up the callback script for 'git rebase run'.
> mktemp \
> | read -r callback;

I like to set a `trap` to remove temp files.

> 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, and use environment
variables to pass 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 :(

I work in detached HEAD mode almost exclusively.  I know, that's..
weird.  But it works for me.  Can we avoid forcing the user to be on a
branch?

Nico
--