On Fri, Feb 1, 2013 at 1:05 PM, Phil Hord <ho...@cisco.com> wrote:
> This is probably right, but it is not exactly the case that caused my itch.
> I think my branch looked like [...]
That also makes sense. I'll add tests for both cases. Your patch makes
both of them pass.
>> # a---b---c
>> # \ \
>> # d \
>> # \ \
>> # e \
>> # \ \
>> # C---l
>> As you say, your patch doesn't try to handle this case, but at least
>> the new behavior seems better. I think we would ideally want the
>> recreated 'l' to have only 'C' as parent in this case. Does that make
> This is not what I meant, but it is a very interesting corner case. I
> am not sure I have a solid opinion on what the result should be here.
Neither do I, so I'll just drop the test case. Thanks.
> Here is the corner case I was thinking of. I did not test this to see
> if this will happen, but I conceived that it might. Suppose you have
> this tree where
> # a---b---c
> # \
> # d---g---l
> # \ /
> # C
> where 'C' introduced the same changes as 'c'.
> When I execute 'git rebase -p l c', I expect that I will end up with
> # a---b---c---d---
> # \ \
> # ---g---l
> That is, 'C' gets skipped because it introduces the same changes already
> seen in 'c'. So 'g' now has two parents: 'd' and 'C^'. But 'C^' is 'd',
> so 'g' now has two parents, both of whom are 'd'.
> I think it should collapse to this instead:
> # a---b---c---d---g---l
I think this is actually what you will get. But I think it will only
be linearized if the branch that should be dropped is the second
parent. I have two tests for this, but I need to simplify them a
little to see that that (parent number) is the only difference.
> I hope this is clear, but please let me know if I made it too confusing.
Very clear. Thanks.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html