Re: [PATCH 01/10] technical doc: add a design doc for the evolve command

> "Stefan Xenos via GitGitGadget" <gitgitgadget@gmail.com> 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?