Re: Should --update-refs exclude refs pointing to the current HEAD?

Stefan Haller <lists@haller-berlin.de> writes:

The point of "update-refs", as I understand it, is that in addition to the end point of the history (E in "git rebase --onto N O E"), any branch tips that are between O..E can be migrated to point at their rewritten counterparts. So I am not sure how it fundamentally solves much by protecting only refs that point at a single commit ("the current HEAD" in your statement).

When I want to see how the rebased history would look like without touching the original, I often rebase a detached HEAD (i.e. instead of the earlier one, use "git rebase --onto N O E^0", or when rebasing the current branch, "git rebase [--onto N] O HEAD^0") and that would protect the current branch well, but --update-refs of course would not work well. There is no handy place like detached HEAD that can be used to save rewritten version of these extra branch tips.

If branch tips A, B, and C are involved in the range of commits being rewritten, one way to help us in such a situation may be to teach "git rebase" to (1) somehow create a new set of proposed-A, proposed-B, and proposed-C refs (they do not have to be branches), while keeping the original A, B, and C intact, (2) allow us to inspect the resulting refs, compare the corresponding ones from these two sets, and (3) allow us to promote (possibly a subset of) proposed- ones to their counterpart real branches after we inspect them. The latter two do not have to be subcommands of "git rebase" but can be separate and new commands.