Re: Heads up: major rebase -i -p rework coming up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

>> - What's with the apostrophe?  I seem to remember that you argued it 
>>   would be enough to make "A" stand for the original when it is used for 
>>   the first time and the second and later use can stand for the result 
>>   of the last use (e.g. the "goto A'" above can be simply spelled as 
>>   "goto A"), when I suggested to use "mark" in a way similar to how 
>>   fast-import language uses it during the sequencer discussion?
>> 
>>   I am not complaining; I am just being curious why the sudden change of 
>>   heart.
>
> Very easy explanation.  I got convinced by your arguments.  Even if I 
> could imagine that I never use the thing without apostrophe, it is good to 
> have an obvious indicator that this is not necessarily the original 
> commit.

Now that does not make much sense to me.

The reason I suggested that 'mark' would give a cleaner semantics was
because in your earlier design "A" could either stand for the original or
it could stand for the result of an operation that used "A", and there
could be more than one operation that uses "A".  Explicitly naming each
result with a mark would give us an unambiguous way to distinguish them.

I however do not think you would ever use A twice in the context of
"rebase -i/-p".  Cherry-picking the same commit twice to create two copies
of them will not happen in that context.

While trying to recreate something like this on top of a commit "o", you
would have to talk about "A" multiple times,...

          B---M
         /   / \
 ---o---A---C   \
     \   \       \
      D---N-------O

... but even in such a picture, after one "pick A", you would always want
to refer to the result of the pick, and never the original A.

    pick A
    goto A'^
    pick D
    merge A' was N
    goto A'
    pick B
    goto A'
    pick C
    merge B' was M
    merge N' was O

So I am inclined to think that "first use refers to the original, second
and thereafter will refer to the result of the first use" would be a good
enough semantics for "rebase -i/-p", and you do not need "A" vs "A'" for
this.

By the way, I think this example shows that your "goto" might need a way
to refer to the "onto" commit in some way (I just used "A'^" there).

On the other hand, if you are aiming to allow users to create (by editing
the insn file) an arbitrarily different structure like this, starting from
the same topology:

  ---o---B---C---A
      \           \
       A---D-------O

that is, rebasing the upper line of development into one linear sequence
with different patch order, while rebasing the lower line into another
linear sequence by rebasing D on top of A, you would need to be able to
refer to the two different results of "using A", and your "A'" notation
would not help.

    pick B
    pick C
    pick A
    goto B'^
    pick A
    pick D
    merge A' was O

The last "merge A' was O" is done while on the result of applying D on top
of the result of applying A on the lower line, and wants to call the tip
of the upper line by referring it as "the result of applying A". 

But there are two results from applying A, and I do not think you can
avoid 'mark', even though you for some reason seem to hate it.

If this kind of transformation is outside the scope of your redesign
(which I think is a sensible design decision), I do not see why you would
need "A vs A'".

You either need the full power of 'mark', or "A is original until it is
used, and then the one and only one result once it is used,"; nothing in
between like "A vs A'" would make much sense.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux