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 just work.-- 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
