Junio C Hamano schrieb:
quoted text
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> On Tue, 29 Apr 2008, Junio C Hamano wrote:
>>> Perhaps it would help to go back to the message J6t incompletely quoted, 
>>> and try the example with the parent order of Y swapped (i.e. B == Y^2, C 
>>> == Y^1)
>>>
>>> Recreating X and Y both need to refer to the rewritten B as the 
>>> parameter to "merge" insn.  You create X first then you cannot refer to 
>>> B anymore to recreate Y.  The other way around you cannot name B to 
>>> recreate X.
>> If you refer to "B" as the "short name of the original commit which refers 
>> to the rewritten commit as soon as B was rewritten", then I really do not 
>> see the problem.
> 
> Hmmm.  Perhaps you are thinking about using not just A, B, C but also
> names like X, Y, and Z in the insn sequence?  I was operating under the
> impression that you used only single parent commits to name things, and a
> name will stand for the result of the last operation that used the name
> (e.g. after "pick B", B names the result of cherry-picking the original B
> to detached HEAD).
> 
> 
>                  A
>                 / \
>                /   X
>               /   / \
>              O---B   Z
>               \   \ /
>                \   Y
>                 \ /
>                  C
> 
>             X = checkout A, merge B
>             Y = checkout C, merge B
>             Z = checkout X, merge Y
> 
> I start from Q, create A', B' and C' with:
> 
> 	reset Q
> 	pick A
>         reset Q
>         pick B
>         reset Q
>         pick C
> 
> Then I can recreate X by doing
> 
> 	reset A
>         merge B
> 
> The problem I had was to figure out the way to go back to "rewritten X".
> I assumed you would say "B" because that is the last insn in the sequence
> that used that name.
> 
> But instead you are thinking of letting me just say "X", and somehow make
> the machinery guess by noticing "Ah, original X is a merge between
> original A and B, and we have a merge between rewritten A and rewritten B,
> so we will treat that merge as rewritten "X"?

You had used this notion in your post:

	merge B -- recreate X

Did you mean the '-- recreate X' part as just a comment? I understood it
as part of the instruction, namely to say that the result of the merge is
the rewritten X. In this case you can refer to X in subsequent insns
unambiguously (keep in mind that it is actually the abbreviated SHA1 of
the original merge commit).

-- Hannes

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html