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

Reply via email to