On Aug 1, 2014, at 12:01 PM, Jakub Narębski <jna...@gmail.com> wrote:
> 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.
> 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
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