All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Nico Williams <nico@cryptonector.com>
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 23:29:40 +0200	[thread overview]
Message-ID: <asFy2kOZe7WDy38I@debian> (raw)
In-Reply-To: <asFw4gsn253MQtxp@ubby>

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

Hi Nico,

> Date: 2026-10-03 16:17:22-0500
> From: Nico Williams <nico@cryptonector.com>
>
> On Sat, Oct 03, 2026 at 11:07:04PM +0200, Alejandro Colomar wrote:
> > Since --abort doesn't go all the way back, I think --continue shouldn't
> > continue all the way forward, for consistency.
> 
> Fair.
> 
> > If that's desired behavior, it should go in this tool, and not as part
> > of git-rebase(1).  git-rebase(1) is a much simpler and much more
> > fundamental tool, which is used to build this more complex tool.
> > That's one reason I'm rather opposed to having this as part of
> > git-rebase(1); it would confuse about the responsibility of
> > git-rebase(1).  IMO, git-rebase(1) is a plumbing command, and
> > git-brebase would be a porcelain thingy.
> > 
> > > If we take this approach then we'd need an option not to enable this
> > > behavior but to disable it, something like `--direct`.
> > 
> > That hints it might be just be a different command.
> 
> If this was 2007, and you were writing the first version of `rebase`,
> and you had already worked out that you wanted this feature, what would
> you do then?  Would you make it the default?  I _think_ I would.
> 
> Basically, this makes rebasing much nicer, so why not make it the
> default?

I'm currently defaulting to brebase for every rebase I want to do.

However, I still use the regular git-rebase(1) for more precise
operations.  To be specific, I use it for changing history (without
moving the base), and I also use it for resolving conflicts as part of
a git-brebase operation.  They seem to me to be different tools, even
though they're clearly related.

I think we use git-rebase(1) for what we should be using git-brebase
only because we didn't have the latter.  That might be the reason we
confuse them and think they're the same tool.  They're used for very
different operations.


Cheers,
Alex

> 
> Nico
> -- 

-- 
<https://www.alejandro-colomar.es>

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

  reply	other threads:[~2026-10-03 21:29 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
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 [this message]
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=asFy2kOZe7WDy38I@debian \
    --to=alx@kernel.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mathstuf@gmail.com \
    --cc=nico@cryptonector.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.