From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:33
Johannes Schindelin [off-list ref] writes:
On Tue, 29 Apr 2008, Junio C Hamano wrote:
quoted
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"?
I actually was hoping we could avoid that, which feels messy.
But now I may be misunderstanding what you meant to say.
From: Johannes Sixt <hidden> Date: 2016-06-15 22:44:33
Junio C Hamano schrieb:
Johannes Schindelin [off-list ref] writes:
quoted
On Tue, 29 Apr 2008, Junio C Hamano wrote:
quoted
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:33
Hi,
On Tue, 29 Apr 2008, Junio C Hamano wrote:
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"?
I actually was hoping we could avoid that, which feels messy.
I cannot bring myself to feel that this is messy. The more I think about
it, the clearer it becomes for me that the pick call should use the
original commit, whereas the merge call should use the rewritten commit
(and should therefore only be called when all ancestors of that merge
which need rebasing were rebased already).
BTW I think that I made a stupid mistake in one of my previous mails: when
I wrote an example for the "merge" command (as I would like it), I did
_not_ list the original commit name of that merge. I.e.
merge <parent2> <parent3>... <message>
I completely forgot that for the $DOTEST/rewritten/ to work, the original
commit name of that merge has to be listed.
But this got me thinking, and I think that to leave out the first parent
was another mistake I made, so I really would like to have this syntax:
merge <orig-commit> <parent1> <parent2>... <message>
This would allow to change the parents in the interactive rebase, and if
<parent1> is not the current commit at that point, it would implicitly
call "reset".
What appeals to me is the simplicity of this approach: you refer to the
commits by calling them by their (original) name.
In the (probably really rare) occasion that you really need to refer to an
original _and_ a rewritten commit, you can always use _any_ commit-ish as
argument to the command.
Ciao,
Dscho
On Wed, Apr 30, 2008 at 09:47:02AM +0100, Johannes Schindelin wrote:
I cannot bring myself to feel that this is messy. The more I think about
it, the clearer it becomes for me that the pick call should use the
original commit, whereas the merge call should use the rewritten commit
(and should therefore only be called when all ancestors of that merge
which need rebasing were rebased already).
Maybe, it would be better if re-written commits were marked a bit
differently, so there will be no confusion about whether an original
or re-written commit is referred. For instance, re-written commits can
be marked by adding apostrophe at the end, so if the original commit
was "abcdef" then the re-written should be called as "abcdef'". At
least, it will make plain clear for anyone where in merge rewritten
commits are mentioned. Otherwise, it looks too magical to me.
Dmitry
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:33
Hi,
On Wed, 30 Apr 2008, Dmitry Potapov wrote:
On Wed, Apr 30, 2008 at 09:47:02AM +0100, Johannes Schindelin wrote:
quoted
I cannot bring myself to feel that this is messy. The more I think about
it, the clearer it becomes for me that the pick call should use the
original commit, whereas the merge call should use the rewritten commit
(and should therefore only be called when all ancestors of that merge
which need rebasing were rebased already).
Maybe, it would be better if re-written commits were marked a bit
differently, so there will be no confusion about whether an original or
re-written commit is referred. For instance, re-written commits can be
marked by adding apostrophe at the end, so if the original commit was
"abcdef" then the re-written should be called as "abcdef'". At least, it
will make plain clear for anyone where in merge rewritten commits are
mentioned. Otherwise, it looks too magical to me.
Fair enough. (For the "too magical" part.)
But it would break down if you picked one commit twice, in order to split
it. OTOH, this is a rare thing, and you really only need to refer to
rewritten commits in the "reset" and "merge" commands.
But there is a bigger problem with what you suggest: When merging a commit
that is _not_ in the rewritten part of the history, adding an apostrophe
is actively wrong.
And I still believe strongly that a regular "rebase -i -p" user will not
want to refer to original commits, except for the "pick" command.
Ciao,
Dscho