Re: cherry picking and merge

From: Jakub Narębski <jnareb@gmail.com>
Date: Aug 6, 2014, 15:58 UTC
Message-ID: <53E25090.7010803@gmail.com>
In-Reply-To: <CAK3OfOhbJJqLB4yPbuJyufytxNUSBLzKF6axc4jeU7eAjvXtgA@mail.gmail.com>

W dniu 2014-08-01 22:55, Nico Williams pisze:

Show 21 quoted lines

> On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Jonathan Nieder wrote:
>>
>>> Do you mean that "git merge" should be aware of what changes you have
>>> already cherry-picked?
>>>
>>> It isn't, and that's deliberate
>>
>> That said, when today's "git merge" fails to resolve conflicts, it's
>> easily possible that we could do better at resolving the merge by
>> walking through both sides and understanding what happened.
>
> It would help if cherry-pick history where recorded somewhere (beyond
> the reflog)...
>
> Cherry-picks should record two parents, like merges.
>
> (Of course, it does no good to know about an unreachable parent, when
> a commit with two parents is pushed to a repo that doesn't have one of
> those parents, which can happen when topic branches aren't pushed
> upstream.)

There was (long time ago) a long thread about idea of adding some kind of 'weak' references (links), 'weakparent' that can be automatically used by Git but do not pollute the commit message, and do not affect reachability calculations. Ultimately it went nowhere (as you can see) - there were many problems.

For example: how it would work for reverts and rebases?

-- 
Jakub Narębski