From: Junio C Hamano <hidden> Date: 2025-11-21 16:01:48
Phillip Wood [off-list ref] writes:
quoted
Granted, I think good progress is being made and perhaps the changes
needed for the rest aren't that huge (and maybe there's more pieces
I'm not quite understanding yet similar to the
two-split-patches-always-summing-to-the-original), I was just a little
surprised that my comments are summarized by "expecting a small and
final reroll". :-)
It was because I didn't think (and I still do not think) your
comments are something for the immediate future, for a tool that
wants to present its minimum-serviceable experimental version to
users so that the users can experiment, extend it more and fix its
behaviour incrementally. I may have been probably wrong, but I was
getting an impression from the reviews that it is getting to there,
not the feature-perfect version that needs only maintenance from now
on, but a minimum-serviceable one.
We could instead of collect all the I want moon and I want cheeze
comments and iterate until the tool has all of them before it hits
'next', but I do not think it is often what we do to a new feature.
Yes I'm not expecting any new functionality but I am expecting a bit
more than tiny cleanup.
OK. Then we'd need a non-trivial amount of work before we get
there.
Thanks.
On Fri, Nov 21, 2025 at 8:01 AM Junio C Hamano [off-list ref] wrote:
Phillip Wood [off-list ref] writes:
quoted
quoted
Granted, I think good progress is being made and perhaps the changes
needed for the rest aren't that huge (and maybe there's more pieces
I'm not quite understanding yet similar to the
two-split-patches-always-summing-to-the-original), I was just a little
surprised that my comments are summarized by "expecting a small and
final reroll". :-)
It was because I didn't think (and I still do not think) your
comments are something for the immediate future, for a tool that
wants to present its minimum-serviceable experimental version to
users so that the users can experiment, extend it more and fix its
behaviour incrementally. I may have been probably wrong, but I was
getting an impression from the reviews that it is getting to there,
not the feature-perfect version that needs only maintenance from now
on, but a minimum-serviceable one.
We could instead of collect all the I want moon and I want cheeze
comments and iterate until the tool has all of them before it hits
'next', but I do not think it is often what we do to a new feature.
You're reading my feedback as feature requests rather than as bugs
and/or possible paint-ourselves-in-a-corner situations in the
presented implementation? I must have described things rather poorly;
if they were just feature requests, I'd agree we could just implement
them later.
But maybe I see where the confusion arises, since you were focusing
solely on the single branch thing; that's the one issue where it's
perhaps not as clear whether I was discussing a bug or a new feature.
Let me try to explain that case another way:
The early cover letters said they focused on a case where just a
single branch was involved, yet they don't check whether there really
is only one branch involved for safe operation.
If a user tries to reword or split a commit that is in the history of
multiple branches, the current implementation does not check and makes
the branches diverge. Some users may want that, though I suspect most
would be negatively surprised. The commit messages and code do not
even discuss this case. If we merge the code as-is and then later
notice and fix this problem soon enough, maybe we'd be fine, but I
always worry a bit about a git-switch/git-restore kind of case where
it sits long enough and people depend on side-effects in a way that
prevents us from fixing it. Besides, since the bug has been
identified and there are multiple not-too-hard ways to fix, I think we
should do something. Some possibilities:
* Document this case and warn users to check on their own (not that
friendly, but might be good enough for the first cut).
* Check if the user-specified commit is part of multiple branches
and error out, unless the user provides a flag verifying that they
want histories to diverge.
* Just rewrite all relevant branches
The third of those could sound like a feature request in isolation,
but I raised it primarily because it's a potential fix to this
overlooked bug. I mentioned all three possible fixes, but assumed
others didn't realize how simple that third option was, so I pointed
out how easy it was with some code (~12 lines, which also replace many
more existing lines of code). I personally think the third option is
*less work* than the second option, and that the focus on trying to
limit to a single branch is creating more work rather than simplifying
the problem. But if folks really do want to limit to a single branch
despite the code existing to handle the more general case, then we can
implement one of the other solutions. (If we do so, I still think
choice three is more friendly to users, to cpus, and to future
extension of these features while also simultaneously simplifying the
existing code; so I'll volunteer to investigate and post patches on
top of this series if others decide to go with one of the other
choices for the initial version of the feature.) My main point here
is just that there is a clear, un-discussed bug, and it should be
addressed somehow in the initial version of the feature.
From: Patrick Steinhardt <hidden> Date: 2025-12-02 18:50:11
On Sat, Nov 22, 2025 at 06:54:00PM -0800, Elijah Newren wrote:
On Fri, Nov 21, 2025 at 8:01 AM Junio C Hamano [off-list ref] wrote:
quoted
Phillip Wood [off-list ref] writes:
quoted
quoted
Granted, I think good progress is being made and perhaps the changes
needed for the rest aren't that huge (and maybe there's more pieces
I'm not quite understanding yet similar to the
two-split-patches-always-summing-to-the-original), I was just a little
surprised that my comments are summarized by "expecting a small and
final reroll". :-)
It was because I didn't think (and I still do not think) your
comments are something for the immediate future, for a tool that
wants to present its minimum-serviceable experimental version to
users so that the users can experiment, extend it more and fix its
behaviour incrementally. I may have been probably wrong, but I was
getting an impression from the reviews that it is getting to there,
not the feature-perfect version that needs only maintenance from now
on, but a minimum-serviceable one.
We could instead of collect all the I want moon and I want cheeze
comments and iterate until the tool has all of them before it hits
'next', but I do not think it is often what we do to a new feature.
You're reading my feedback as feature requests rather than as bugs
and/or possible paint-ourselves-in-a-corner situations in the
presented implementation? I must have described things rather poorly;
if they were just feature requests, I'd agree we could just implement
them later.
The command is explicitly marked as experimental so that we can iterate
on its behaviour as needed. So I don't think we're painting us into a
corner yet.
But maybe I see where the confusion arises, since you were focusing
solely on the single branch thing; that's the one issue where it's
perhaps not as clear whether I was discussing a bug or a new feature.
Let me try to explain that case another way:
The early cover letters said they focused on a case where just a
single branch was involved, yet they don't check whether there really
is only one branch involved for safe operation.
I think this depends on the definition. We _do_ verify that the commit
that is to be edited is part of the current branch. What we _don't_
check is that the commit is _only_ part of that current branch.
I'm not sure whether that is something we want. I myself have the same
commit on multiple branches quite regularly, as I tend to queue up
multiple dependent patch series. But I wouldn't ever want a history edit
to affect all of these branches myself, I really only want it to modify
the branch I'm currently on.
If a user tries to reword or split a commit that is in the history of
multiple branches, the current implementation does not check and makes
the branches diverge. Some users may want that, though I suspect most
would be negatively surprised. The commit messages and code do not
even discuss this case. If we merge the code as-is and then later
notice and fix this problem soon enough, maybe we'd be fine, but I
always worry a bit about a git-switch/git-restore kind of case where
it sits long enough and people depend on side-effects in a way that
prevents us from fixing it. Besides, since the bug has been
identified and there are multiple not-too-hard ways to fix, I think we
should do something. Some possibilities:
* Document this case and warn users to check on their own (not that
friendly, but might be good enough for the first cut).
* Check if the user-specified commit is part of multiple branches
and error out, unless the user provides a flag verifying that they
want histories to diverge.
* Just rewrite all relevant branches
The third of those could sound like a feature request in isolation,
but I raised it primarily because it's a potential fix to this
overlooked bug. I mentioned all three possible fixes, but assumed
others didn't realize how simple that third option was, so I pointed
out how easy it was with some code (~12 lines, which also replace many
more existing lines of code). I personally think the third option is
*less work* than the second option, and that the focus on trying to
limit to a single branch is creating more work rather than simplifying
the problem. But if folks really do want to limit to a single branch
despite the code existing to handle the more general case, then we can
implement one of the other solutions. (If we do so, I still think
choice three is more friendly to users, to cpus, and to future
extension of these features while also simultaneously simplifying the
existing code; so I'll volunteer to investigate and post patches on
top of this series if others decide to go with one of the other
choices for the initial version of the feature.) My main point here
is just that there is a clear, un-discussed bug, and it should be
addressed somehow in the initial version of the feature.
So with the above clarification I wouldn't call any of this a bug, but
rather working as designed. We could of course still print a warning in
that case to protect the user, but one problem I see is that generating
this warning could be quite expensive as we'd now have to walk all
references. That might be cheap in case the user only has short-lived
feature branchs. But it may very well not be cheap in case they for
example have old release branches checked out, as we'd now have to
potentially walk a significant portiion of history.
Consequently I'm leaning more into the direction of doing nothing. It's
not really clear to me that this is a bug, and we still can introduce a
flag in the future that opts into the behaviour of rewriting relevant
branches. That behaviour certainly can be useful, but I'd claim that
it would be rather surprising to the user if that was the default.
Patrick
On Tue, Dec 2, 2025 at 10:50 AM Patrick Steinhardt [off-list ref] wrote:
On Sat, Nov 22, 2025 at 06:54:00PM -0800, Elijah Newren wrote:
quoted
On Fri, Nov 21, 2025 at 8:01 AM Junio C Hamano [off-list ref] wrote:
quoted
Phillip Wood [off-list ref] writes:
quoted
quoted
Granted, I think good progress is being made and perhaps the changes
needed for the rest aren't that huge (and maybe there's more pieces
I'm not quite understanding yet similar to the
two-split-patches-always-summing-to-the-original), I was just a little
surprised that my comments are summarized by "expecting a small and
final reroll". :-)
It was because I didn't think (and I still do not think) your
comments are something for the immediate future, for a tool that
wants to present its minimum-serviceable experimental version to
users so that the users can experiment, extend it more and fix its
behaviour incrementally. I may have been probably wrong, but I was
getting an impression from the reviews that it is getting to there,
not the feature-perfect version that needs only maintenance from now
on, but a minimum-serviceable one.
We could instead of collect all the I want moon and I want cheeze
comments and iterate until the tool has all of them before it hits
'next', but I do not think it is often what we do to a new feature.
You're reading my feedback as feature requests rather than as bugs
and/or possible paint-ourselves-in-a-corner situations in the
presented implementation? I must have described things rather poorly;
if they were just feature requests, I'd agree we could just implement
them later.
The command is explicitly marked as experimental so that we can iterate
on its behaviour as needed. So I don't think we're painting us into a
corner yet.
I'm aware it's marked as experimental and even commented on that at
least once in this series. I'm not sure that's sufficient _in this
kind of case_ for the following reasons:
* Users tend to not have multiple branches sharing commits and then
try to operate on those, it will only come up rarely. (I still think
it's a very important usecase, just that it's not common, in part
because git has trained people away from this kind of usecase.)
* Since the command is marked as experimental, it might extend the
timeline until we see such uses.
* The implemented behavior is not always a bug, some users will want
it (it's the kind of thing that makes sense as an option).
Combining the above, it might be a long time before folks really hit
this behavior and start pointing out its problems, rather than hitting
them early on. By then, we don't know how many users we have, just
that it's been a long time, and we are further faced with the fact
that some subset of users have begun to depend upon the existing
behavior. The combination may make it hard to change at that point.
To me, it feels very much like risking painting ourselves into a
corner. If it were an issue I felt people would likely hit right away
OR it was an issue which users would always view as a bug, then I'd
agree with you that there's no (or very little) risk with just
proceeding as-is.
quoted
But maybe I see where the confusion arises, since you were focusing
solely on the single branch thing; that's the one issue where it's
perhaps not as clear whether I was discussing a bug or a new feature.
Let me try to explain that case another way:
The early cover letters said they focused on a case where just a
single branch was involved, yet they don't check whether there really
is only one branch involved for safe operation.
I think this depends on the definition. We _do_ verify that the commit
that is to be edited is part of the current branch. What we _don't_
check is that the commit is _only_ part of that current branch.
I'm not sure whether that is something we want. I myself have the same
commit on multiple branches quite regularly, as I tend to queue up
multiple dependent patch series. But I wouldn't ever want a history edit
to affect all of these branches myself, I really only want it to modify
the branch I'm currently on.
To me at least, that feels crazy. Rebase was broken for multiple
interconnected or dependent branches precisely because you could only
update one branch, then needed to find the subset of the next branch
not contained in the first as well as finding where to graft that next
set onto in order to manually rebase it, then repeat for the third
branch, and so on. That's precisely the design mistake that made me
give up on rebase and write something else...and you want to
explicitly copy it?
(--update-refs did come along later to help in the common case that
each new branch fully contained the previous ones, but it didn't help
when you had multiple branches that built on some common base, or had
other interesting topologies, and thus didn't really fix the
underlying problem.)
quoted
If a user tries to reword or split a commit that is in the history of
multiple branches, the current implementation does not check and makes
the branches diverge. Some users may want that, though I suspect most
would be negatively surprised. The commit messages and code do not
even discuss this case. If we merge the code as-is and then later
notice and fix this problem soon enough, maybe we'd be fine, but I
always worry a bit about a git-switch/git-restore kind of case where
it sits long enough and people depend on side-effects in a way that
prevents us from fixing it. Besides, since the bug has been
identified and there are multiple not-too-hard ways to fix, I think we
should do something. Some possibilities:
* Document this case and warn users to check on their own (not that
friendly, but might be good enough for the first cut).
* Check if the user-specified commit is part of multiple branches
and error out, unless the user provides a flag verifying that they
want histories to diverge.
* Just rewrite all relevant branches
[...]
So with the above clarification I wouldn't call any of this a bug, but
rather working as designed. We could of course still print a warning in
that case to protect the user, but one problem I see is that generating
this warning could be quite expensive as we'd now have to walk all
references. That might be cheap in case the user only has short-lived
feature branchs. But it may very well not be cheap in case they for
example have old release branches checked out, as we'd now have to
potentially walk a significant portiion of history.
Munging user's histories in unexpected ways and depending on them to
figure out on their own that such has happened may well be much more
expensive. Granted, that's human time rather than cpu time, so it's
not directly comparable, but this feels like a big foot-gun, and I
think big foot-guns deserve good checks and warnings. I agree there's
a cost here, but I think the cost is warranted, especially since such
an error message would be the thing that frees us to iterate and
define the multi-branch behavior later.
Consequently I'm leaning more into the direction of doing nothing. It's
not really clear to me that this is a bug, and we still can introduce a
flag in the future that opts into the behaviour of rewriting relevant
branches. That behaviour certainly can be useful, but I'd claim that
it would be rather surprising to the user if that was the default.
Well, as I stated above, this is basically copying what I view as the
fundamental design mistake of git-rebase. The many other points of
feedback I had on this series (e.g. extended headers, reusing replay's
walking, etc.) are things I could easily negotiate on; this one
bothers me much, much more. To me, it ruins the command and makes me
feel it is unsuitable for inclusion in git; this is, after all, the
kind of thing that made me decide to write yet another command to
workaround such a flaw. If the series is merged with this behavior,
I'm going to be in the awkward position of feeling I need to actively
recommend against its usage unless _and until_ we either
(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.
From: Patrick Steinhardt <hidden> Date: 2025-12-09 07:53:40
On Fri, Dec 05, 2025 at 12:49:04AM -0800, Elijah Newren wrote:
On Tue, Dec 2, 2025 at 10:50 AM Patrick Steinhardt [off-list ref] wrote:
quoted
Consequently I'm leaning more into the direction of doing nothing. It's
not really clear to me that this is a bug, and we still can introduce a
flag in the future that opts into the behaviour of rewriting relevant
branches. That behaviour certainly can be useful, but I'd claim that
it would be rather surprising to the user if that was the default.
Well, as I stated above, this is basically copying what I view as the
fundamental design mistake of git-rebase. The many other points of
feedback I had on this series (e.g. extended headers, reusing replay's
walking, etc.) are things I could easily negotiate on; this one
bothers me much, much more. To me, it ruins the command and makes me
feel it is unsuitable for inclusion in git; this is, after all, the
kind of thing that made me decide to write yet another command to
workaround such a flaw. If the series is merged with this behavior,
I'm going to be in the awkward position of feeling I need to actively
recommend against its usage unless _and until_ we either
(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.
Do we already have logic like this in git-replay(1)?
Patrick
From: Martin von Zweigbergk <hidden> Date: 2025-12-09 17:43:54
On Mon, Dec 8, 2025 at 11:53 PM Patrick Steinhardt [off-list ref] wrote:
On Fri, Dec 05, 2025 at 12:49:04AM -0800, Elijah Newren wrote:
quoted
On Tue, Dec 2, 2025 at 10:50 AM Patrick Steinhardt [off-list ref] wrote:
quoted
Consequently I'm leaning more into the direction of doing nothing. It's
not really clear to me that this is a bug, and we still can introduce a
flag in the future that opts into the behaviour of rewriting relevant
branches. That behaviour certainly can be useful, but I'd claim that
it would be rather surprising to the user if that was the default.
Well, as I stated above, this is basically copying what I view as the
fundamental design mistake of git-rebase. The many other points of
feedback I had on this series (e.g. extended headers, reusing replay's
walking, etc.) are things I could easily negotiate on; this one
bothers me much, much more. To me, it ruins the command and makes me
feel it is unsuitable for inclusion in git; this is, after all, the
kind of thing that made me decide to write yet another command to
workaround such a flaw. If the series is merged with this behavior,
I'm going to be in the awkward position of feeling I need to actively
recommend against its usage unless _and until_ we either
(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. 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`.
Do we already have logic like this in git-replay(1)?
Patrick
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
On Mon, Dec 8, 2025 at 11:53 PM Patrick Steinhardt [off-list ref] wrote:
On Fri, Dec 05, 2025 at 12:49:04AM -0800, Elijah Newren wrote:
quoted
On Tue, Dec 2, 2025 at 10:50 AM Patrick Steinhardt [off-list ref] wrote:
quoted
Consequently I'm leaning more into the direction of doing nothing. It's
not really clear to me that this is a bug, and we still can introduce a
flag in the future that opts into the behaviour of rewriting relevant
branches. That behaviour certainly can be useful, but I'd claim that
it would be rather surprising to the user if that was the default.
Well, as I stated above, this is basically copying what I view as the
fundamental design mistake of git-rebase. The many other points of
feedback I had on this series (e.g. extended headers, reusing replay's
walking, etc.) are things I could easily negotiate on; this one
bothers me much, much more. To me, it ruins the command and makes me
feel it is unsuitable for inclusion in git; this is, after all, the
kind of thing that made me decide to write yet another command to
workaround such a flaw. If the series is merged with this behavior,
I'm going to be in the awkward position of feeling I need to actively
recommend against its usage unless _and until_ we either
(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.
Do we already have logic like this in git-replay(1)?
No, git-replay was written from the beginning with the idea in mind of
handling multiple branches (e.g. letting Junio edit a single commit in
someone's topic and updating all the subsequent commits and merges
without having to individually fuss with them all, or similarly for
the Git For Windows or Microsoft Git forks, or at a smaller level if I
have multiple topics that share a few commits and I want to update one
of those), so the idea was always (c) by default, with options for
alternate behavior, which is kind of the opposite angle you are
approaching from. Anyway, because of that view, nothing like (a) was
ever implemented.
On Tue, Dec 2, 2025, at 19:49, Patrick Steinhardt wrote:
quoted
[snip]
I'm not sure whether that is something we want. I myself have the same
commit on multiple branches quite regularly, as I tend to queue up
multiple dependent patch series. But I wouldn't ever want a history edit
to affect all of these branches myself, I really only want it to modify
the branch I'm currently on.
Let’s say with the current subcommands I want to
• Split a commit because it contains unrelated formatting fixups
• I want to fix typos in a commit message and also add a paragraph
Then let’s say that there are three branches that contain these commits.
I can’t think of a case where I intend to only make these changes for
one of the branches.
A default of update-all-branches-in-range seems like the best default.
I also agree with everything Elijah wrote here:
https://lore.kernel.org/git/CABPp-BFtx7-vLFbVqbHar=UZb1CGX5=ufMA4hrJRkSYuB14_Tw@mail.gmail.com/
I haven’t used Jujutsu yet. But apparently it is much less
branch-focused. But for us who use branches and sometimes need
“dependent branches” or “stacked branches” the default equivalent of
`--update-refs` seems like a win to me.
Okay, maybe let’s say that I am really making intentionally-divergent
histories and one commit needs to be reworded for that divergent
context. That could happen. But I can’t imageine where I would do that.
[snip]
Consequently I'm leaning more into the direction of doing nothing. It's
not really clear to me that this is a bug, and we still can introduce a
flag in the future that opts into the behaviour of rewriting relevant
branches. That behaviour certainly can be useful, but I'd claim that
it would be rather surprising to the user if that was the default.
Maybe it’s surprising with the current defaults of other commands. But
for a new-and-better (for some circumstances or all) commands defaulting
to updating all branches sounds great.
I have read or heard about the “mega merge” strategy in Jujutsu.[1]
Being able to (this is how I imagine it could work) make a temporary
integration branch where N branches can be edited by making edits to
them and having all the branches be updated sounds amazing.[2][3] I have
found myself doing temporary integration branches where I make fixes on
top and manually cherry-picking them to the correct target afterwards.
🔗 1: https://news.ycombinator.com/item?id=44650248
† 2: Maybe the commits are “edited” and then the integration merges are
re-done which sounds simple in the case of splitting commits and
rewording commit messages. Well, “simple”, that’s easy for me to
say from the peanut gallery. :) (I am aware that git-history(1)
does not support merges in this current iteration)
† 3: I am thinking of the “common case” of `-update-refs` but what
Elijah pointed out about “other interesting topologies” sounds even
better. :) In the link from above:
https://lore.kernel.org/git/CABPp-BFtx7-vLFbVqbHar=UZb1CGX5=ufMA4hrJRkSYuB14_Tw@mail.gmail.com/
From: D. Ben Knoble <hidden> Date: 2025-12-12 22:01:14
On Tue, Dec 9, 2025 at 1:29 PM Kristoffer Haugsbakk
[off-list ref] wrote:
On Tue, Dec 2, 2025, at 19:49, Patrick Steinhardt wrote:
quoted
quoted
[snip]
I haven’t used Jujutsu yet.
Same, however:
I have read or heard about the “mega merge” strategy in Jujutsu.[1]
Being able to (this is how I imagine it could work) make a temporary
integration branch where N branches can be edited by making edits to
them and having all the branches be updated sounds amazing.[2][3] I have
found myself doing temporary integration branches where I make fixes on
top and manually cherry-picking them to the correct target afterwards.
I have done something like this once. Created a few independent
branches, wrangled an octopus merge together, and then worked on top
of that. When I wanted to commit, I did "commit --fixup" with the
appropriate branch/commit, then eventually "rebase --autosquash
--rebase-merges" or something. In that particular case, I started with
empty commits on each branch, I think.
You could probably shuffle commits (like to add a new one to a sub
branch) using "rebase --interactive…" there, too, but I don't think I
tried that.
Anyway, the workflow did its job, but I didn't end up with something I
think I'd try in practice very often, at least not yet. It did make me
wonder what from jj we'd need to make things smoother, though.
--
D. Ben Knoble