From: Alejandro Colomar Date: Sat, 03 Oct 2026 21:29:40 GMT Subject: Re: [RFC] git-brebase Message-ID: In-Reply-To: Hi Nico, > Date: 2026-10-03 16:17:22-0500 > From: Nico Williams > > 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 > -- --