Git development
 help / color / mirror / Atom feed
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
-- 

  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