All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.