From: Nico Williams <nico@cryptonector.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Ben Boeckel <mathstuf@gmail.com>,
Viktor Dukhovni <viktor@openssl.org>
Subject: Re: [RFC] git-brebase
Date: Sat, 3 Oct 2026 15:39:41 -0500 [thread overview]
Message-ID: <asFoDZKscLKqaIf+@ubby> (raw)
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
--
next prev parent reply other threads:[~2026-10-03 21:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-03 20:11 [RFC] git-brebase Alejandro Colomar
2026-10-03 20:13 ` Alejandro Colomar
2026-10-03 20:39 ` Nico Williams [this message]
2026-10-03 20:48 ` Nico Williams
2026-10-03 21:07 ` Alejandro Colomar
2026-10-03 21:17 ` Nico Williams
2026-10-03 21:29 ` Alejandro Colomar
2026-10-03 21:50 ` Nico Williams
2026-10-03 20:56 ` Alejandro Colomar
2026-10-03 21:13 ` Nico Williams
2026-10-03 21:38 ` Alejandro Colomar
2026-10-03 22:19 ` Nico Williams
2026-10-03 21:17 ` Alejandro Colomar
2026-10-08 22:18 ` [RFC v3] git-bisect-rebase Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=asFoDZKscLKqaIf+@ubby \
--to=nico@cryptonector.com \
--cc=alx@kernel.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mathstuf@gmail.com \
--cc=viktor@openssl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox