On 28/09/2022 23:20, Junio C Hamano wrote:
"Stefan Xenos via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
+Rebase
+------
+In general the rebase command is treated as a modify command. When a change is
+rebased, the new commit replaces the original.
+
+Rebase --abort is special. Its intent is to restore git to the state it had
+prior to running rebase. It should move back any changes to point to the refs
+they had prior to running rebase and delete any new changes that were created as
+part of the rebase. To achieve this, rebase will save the state of all changes
+in refs/metas prior to running rebase and will restore the entire namespace
+after rebase completes (deleting any newly-created changes).
That wont work now that we have multiple worktrees. If a user starts two
rebases of two different branches in two different worktrees and aborts
one of them we loose the new meta-commits of both. Each rebase will need
to track which refs under refs/metas/ it has updated (that will also
save the overhead of copying the entire refs/metas/ subtree).
Newly-created
+metacommits are left in place, but will have no effect until garbage collected
+since metacommits are only used if they are reachable from refs/metas.
One thing that makes me nervous is how well your analysis capture
"unusual" but still reasonable ways to use these commands, as the
workflows of people are quite different.
For example, I almost never do "git checkout topic && git rebase
origin"; instead I would do "git checkout topic && git rebase origin
HEAD^0" to first make a detached HEAD out of the topic, in order to
have two copies explicitly available to be compared after "rebase"
finishes. After doing so and get satisfied by the result of
comparison between topic and HEAD, I may do "git checkout -B topic"
to update. Would that leave exactly the same set of metacommits as
the case where I didn't do the "first rebase the detached HEAD and
then update the bracnh for real" and instead "rebase the topic"
directly?
As I understand it we have a ref under refs/metas/ for each commit. If
that understanding is correct the two cases you describe should be
recorded identically I think.
Best Wishes
Phillip
