Re: cherry picking and merge
On Aug 1, 2014, at 12:01 PM, Jakub Narębski <jnareb@gmail.com> wrote:
Show 6 quoted lines
> It can work in Subversion because Subversion stores information about
> what was merged in (and this includes cherry-picks, or whatever it is
> named in svn) in svn:mergeinfo property. Git does not track what was
> merged in, instead it represent the history as the graph of revisions,
> and tracks merges (by storing that it came from two or more commits)
> and not merged-in information.
So, as a dumb user that just wants it to work, I am unsympathetic to the `but software is hard’ excuse. I am aware that some bugs are harder to fix than others. svn took a long time to fix this bug, but they did. I can wait, the only question is, will it be a week, a month, a year, or a decade.
> When merging Git uses only what is being merged and its common
> ancestor (3-point merge). It is simple, and simple works!!!
I gave a solution for git using branches and it works just fine. It retains the simple 3-point merge as well.
> Unfortunately, it does not see cherry-picked commits - it is invisible
> to merge as being on the chain from one of merged commits to the
> common ancestor.
Im the solution that I sketched in my previous email, that information is then exposed so that the right merge happens.
> The rebase command handles
I can’t use rebase as it is unfriendly to coworkers.
Show 5 quoted lines
> cherry-picked commits by detecting that the
> change was already applied. I think that git-imerge does the same (but
> I have not used it myself).
>
> Have you tried git-imerge?
No, not yet. I’m not as interested in using it, as I would like git itself to just work.