Re: Commit dropped when swapping commits with rebase -i -p

From: Andreas Heiduk <asheiduk@gmail.com>
Date: Sep 16, 2017, 10:41 UTC
Message-ID: <9e004c75-bc35-06ae-8479-9440059c4d0f@gmail.com>
In-Reply-To: <xmqqbmmbwuq0.fsf@gitster.mtv.corp.google.com>

Am 15.09.2017 um 22:52 schrieb Junio C Hamano:

Show 15 quoted lines

> Sebastian Schuberth <sschuberth@gmail.com> writes:
>>
>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
>> index 6805a74aec..ccd0a04d54 100644
>> --- a/Documentation/git-rebase.txt
>> +++ b/Documentation/git-rebase.txt
>> @@ -782,10 +782,11 @@ case" recovery too!
>>  
>>  BUGS
>>  ----
>> -The todo list presented by `--preserve-merges --interactive` does not
>> -represent the topology of the revision graph.  Editing commits and
>> -rewording their commit messages should work fine, but attempts to
>> -reorder commits tend to produce counterintuitive results.
>> +Be careful when combining the `-i` / `--interactive` and `-p` /

"Be careful" is not necessary because the text is already in the "BUGS" section.

Show 15 quoted lines

>> +`--preserve-merges` options.  Reordering commits will drop commits from the
>> +main line. This is because the todo list does not represent the topology of the
>> +revision graph in this case.  However, editing commits and rewording their
>> +commit messages 'should' work fine.
>>  
>>  For example, an attempt to rearrange
>>  ------------
> 
> 
> Anybody?  I personally feel that the updated text is not all that
> stronger but it is clearer by clarifying what "counterintuitive
> results" actually mean, but I am not the target audience this
> paragraph is trying to help, nor I am the one who is making excuse
> for a known bug, so...
>

For me the proposed wording implies that the only bad effect are dropped commits on the mainline. But I experienced something like this:

O--O--O--O---M--O        ==>   O--O--O--O---M--O
 \          /                   \          /
  O--X--O--O                     O--X     O

Where X was a commit without a ref and hence lost. Also the merge commit seemed to combine two unrelated histories.

Therefore I would avoid "definitive wording" like "will drop" and use vague wording along "there are various dragons out there" like this:

    The todo list presented by `--preserve-merges --interactive` does
    not represent the topology of the revision graph.  Editing
    commits and rewording their commit messages should work fine.
    But reordering, combining or dropping commits of a complex topology
    can produce unexpected and useless results like missing commits,
    wrong merges, merges combining two unrelated histories and
    similar things.