Re: [PATCH 13/22] sequencer: remember the onelines when parsing the todo file

From: Jakub Narębski <jnareb@gmail.com>
Date: Sep 9, 2016, 19:06 UTC
Message-ID: <5b707a0d-6c10-abb5-3213-d13490e9b9de@gmail.com>
In-Reply-To: <alpine.DEB.2.20.1609091708480.129229@virtualbox>

Hello Johannes,

W dniu 09.09.2016 o 17:12, Johannes Schindelin napisał:

> On Thu, 1 Sep 2016, Junio C Hamano wrote: 
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 12 quoted lines

>> I was sort of expecting that, when you do the preserve-merges mode
>> of "rebase -i", you would need to jump around, doing "we have
>> reconstructed the side branch on a new 'onto', let's give the result
>> this temporary name ':1', and then switch to the trunk (which would
>> call for 'reset <commit>' instruction) and merge that thing (which
>> would be 'merge :1' or perhaps called 'pick :1')", and at that point
>> you no longer validate the object references upfront.
> 
> Except that is not how --preserve-merges works: it *still* uses the SHA-1s
> as identifiers, even when the SHA-1 may have changed in the meantime.
> 
> That is part of why it was a bad design.

When preserving merges, there are (as far as I understand it), two
problems:
 - what it means to preserve changes (which change to pick,
   that is what is the mainline changes rebase is re-applying)
 - what are parents of the merge commit (at least one parent
   would be usually rewritten)

Maybe the internal (and perhaps also user-visible) representation of merge in instruction sheet could use the notation of filter-branch, that is 'map(<sha-1>)'... it could also imply the mainline.

That is the instruction in the internal instruction sheet could look like this:

  merge -m 1 map(2fd4e1c67a2d28fced849ee1bb76e7391b93eb12) da39a3ee5e6b4b0d3255bfef95601890afd80709 \t Merge 'foo' into master

Note that it has nothing to do with this series!

Best regards,

-- 
Jakub Narębski