Re: cherry picking and merge
- From
- Nico Williams <nico@cryptonector.com>
- Date
- Aug 1, 2014, 20:55 UTC
- Message-ID
- <CAK3OfOhbJJqLB4yPbuJyufytxNUSBLzKF6axc4jeU7eAjvXtgA@mail.gmail.com>
- In-Reply-To
- <20140801205040.GT12427@google.com>
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 10 quoted lines
> 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.)
Nico --