Re: [PATCH v3 0/4] history: add squash subcommand to fold a range

[Patrick Steinhardt <ps@pks.im>]

On Thu, Jun 18, 2026 at 05:34:44PM -0700, Junio C Hamano wrote:
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > Adds git history squash <revision-range> to fold a range of commits into its
> > oldest one, reusing that commit's message and replaying any descendants on
> > top.
> 
> One thing that just occurred to me.
> 
> When you have a linear history
> 
>     o---A---B---C
> 
> you run "git history squash A..C" and come to
> 
>     o---X
> 
> where the tree of X is the same as C, with the log message of A
> reused for it.  That is simple, clean, and easy to explain.
> 
> But what should happen to refs (i.e., branch head) that point at A
> or B?

It's a very good question. I had `git history squash` in my backlog for
a while, and this very question made me defer that topic repeatedly.

> I am adressing this message to Patrick as this question relates to
> the grand vision for the "git history" command.  I think "git
> replay" wants to rewrite all the refs that are involved in the
> rewrite operation, while "git rebase" (without "--update-refs")
> wants to leave all others refs intact and update only the branch it
> was told to rewrite.  Is it the same design as "rebase" and
> "--update-refs" controls if we update _other_ refs that happened to
> be in the range that are rewritten?

Yeah.

> Now, assuming that there do exist a mode where the command can
> update these refs that point into the history that got rewritten,
> there probably are at least two possibilities.
> 
> On one hand, I think it is reasonable to _remove_ these refs that
> used to point at a section of history that disappeared (like the one
> that were pointing at A or B).  Perhaps A and B were pointed at by
> two branches or tags that were used to mark "up to this point things
> are broken" and "from here on things are fixed" (i.e., imagine a
> manual bisection).  After squashing all of the commits in this
> section of history, the result no longer has such transition points.

I think just pruning references would be extremely surprising to our
users.

> It also is plausible that users may want these refs that used to
> point at A or B to point at X, just like the ref that used to point
> at C would now point at X, even though I cannot offhand think of a
> good story (like "there used to be transtion points, now there
> isn't" I said above to explain why these refs should disappear) to
> support such a behaviour.
>
> Thoughts?

There are two more modes:

  - If a reference points at an intermediate commit then it stays there.

  - We detect this case and reject the update. Optionally, we may ask
    the user what they intend to do with those other refs.

It really is kind of ambiguous what is supposed to happen, and I can
think of different scenarios where each of the possibilities would be
the best choice. So ultimately, I think the last option is the best one,
as it also gives us a way to iterate.

If so, a user would already be able to achieve that other refs keep
pointing at X by saying `git history squash --update-refs=head`. The
other modes can then be added at a later point in time as the need
arises.

Patrick