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

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

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?

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?

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.

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?