"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). 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?
