Re: [PATCH v6 00/11] Introduce git-history(1) command for easy history editing

On 09/12/2025 17:43, Martin von Zweigbergk wrote:

On Mon, Dec 8, 2025 at 11:53 PM Patrick Steinhardt [off-list ref] wrote:

quoted

On Fri, Dec 05, 2025 at 12:49:04AM -0800, Elijah Newren wrote:

quoted

(a) check that a commit is only part of one branch before proceeding,
(b) always require the user to specify with a flag how to handle
commits that happen to be part of multiple branches (even when a
commit only happens to be part of one branch, in order to allow us to
not bother checking whether it's part of more),
or
(c) rewrite all branches that contain the given commit by default
(with an option to only rewrite the current one).

That said, obviously the choice of whether the series is merged isn't
up to me.  And maybe I'm in the minority, and others don't care about
this issue at all.  But it's how I feel about it.

I guess it's a matter of workflows and tastes, and there's never going
to be the one correct way of doing things. I don't think (b) is a good
option as it makes things more complex even for the simplest cases. But
I wouldn't be opposed to a combination of (a) and (b) if we can
implement (a) efficiently.

FWIW, I agree with Elijah that (c) is the right end state.

FWIW I think so too, but there does seem to be a significant number of 
people who find that behavior surprising so maybe we need a flag to 
control what gets rewritten.

Thanks

Phillip

That's
perhaps not surprising given that that's what jj has been doing for
many years (as many of you know already, I'm one of the jj
maintainers). I think it's very rare that we hear from users that they
want to rewrite a commit and its descendants while leaving some of the
descendants in place. We have a `jj duplicate` command they can use,
but that won't move any bookmarks (branches) over. So if you have
bookmark `foo` with descendant bookmarks `bar` and `baz` and you want
to amend `foo` while moving `bar` over and keeping `baz` in place, the
simplest way is probably to duplicate all the necessary commit
(something like `jj duplicate -r main..bar`) and then manually move
over `foo` and `bar`. That seems like such a rare use case that we
haven't had a reason to make it simpler so far.

Regarding performance of (a), I would think that walking all
branches/tags until you reach the to-be-modified commit (or reach an
older generation) can usually be done quickly enough, but obviously
there are many others on this list who know that better than me :) But
I have also heard that some Git repos have tens (hundreds?) of
thousands of branches. Hopefully those refs are just on some server
where users won't run `git history`.

quoted

Do we already have logic like this in git-replay(1)?

Patrick