* [Discussion] cherry-picking a merge
@ 2007-11-15 8:00 Junio C Hamano
2007-11-15 8:16 ` Shawn O. Pearce
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2007-11-15 8:00 UTC (permalink / raw)
To: git
Earlier "git cherry-pick" learned the "-m <parent-number>"
option to allow cherry-picking a merge commit.
When you have this history:
---o---o---C---A---M
\ /
o---o-------B
You can replay the change between A and M (in other words, the
effect of merging B into A) on top of C to create a new commit,
with:
$ git cherry-pick -m 1 M
In the current implementation, the resulting commit has a single
parent C. This is quite similar to a squash merge of B into C.
When you think about it, as long as the topological relationship
between A and B is very similar to that of C and B (iow,
"merge-base A B" and "merge-base C B" are the same), the effect
should be the same as a real merge between B and C, shouldn't it?
---o---o---C---A---M
\ \ /
o---o---\---B
\ \
`---X
I am wondering if it makes sense to record the result of
"cherry-pick -m" as a real merge between the current HEAD and
all the other parents of the cherry-picked merge except the one
that is named with the <parent-number>.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Discussion] cherry-picking a merge
2007-11-15 8:00 [Discussion] cherry-picking a merge Junio C Hamano
@ 2007-11-15 8:16 ` Shawn O. Pearce
2007-11-15 17:40 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Shawn O. Pearce @ 2007-11-15 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> wrote:
> You can replay the change between A and M (in other words, the
> effect of merging B into A) on top of C to create a new commit,
> with:
>
> $ git cherry-pick -m 1 M
>
> In the current implementation, the resulting commit has a single
> parent C. This is quite similar to a squash merge of B into C.
>
> When you think about it, as long as the topological relationship
> between A and B is very similar to that of C and B (iow,
> "merge-base A B" and "merge-base C B" are the same), the effect
> should be the same as a real merge between B and C, shouldn't it?
>
> ---o---o---C---A---M
> \ \ /
> o---o---\---B
> \ \
> `---X
>
> I am wondering if it makes sense to record the result of
> "cherry-pick -m" as a real merge between the current HEAD and
> all the other parents of the cherry-picked merge except the one
> that is named with the <parent-number>.
Yes.
Then `rebase -i` might be able to learn how to "pick" merge commits.
And then my coworkers can stop bothering me about that. And just
do it themselves.
I used to think of merges as something special. I now really only
look at them as being special *during* the merge process, as you
may need to generate that recursive base. But otherwise its just
"diff M^1..M". So why isn't it?
:-)
--
Shawn.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Discussion] cherry-picking a merge
2007-11-15 8:16 ` Shawn O. Pearce
@ 2007-11-15 17:40 ` Junio C Hamano
0 siblings, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2007-11-15 17:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> When you think about it, as long as the topological relationship
>> between A and B is very similar to that of C and B (iow,
>> "merge-base A B" and "merge-base C B" are the same), the effect
>> should be the same as a real merge between B and C, shouldn't it?
>>
>> ---o---o---C---A---M
>> \ \ /
>> o---o---\---B
>> \ \
>> `---X
>>
>> I am wondering if it makes sense to record the result of
>> "cherry-pick -m" as a real merge between the current HEAD and
>> all the other parents of the cherry-picked merge except the one
>> that is named with the <parent-number>.
>
> Yes.
Actually, this turns to be a trick question ;-)
If there was an accidental clean merge between A and B, and a
part of the duplicated same changes in the accidental clean
merge sits between C and A, replaying the difference from A to M
on top of C would not yield the same result as merging B into C.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-11-15 17:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-15 8:00 [Discussion] cherry-picking a merge Junio C Hamano
2007-11-15 8:16 ` Shawn O. Pearce
2007-11-15 17:40 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.