Re: cherry picking and merge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Mike Stump" <mikestump@xxxxxxxxxxx>
Sent: Friday, August 01, 2014 11:24 PM
On Aug 1, 2014, at 12:01 PM, Jakub Narębski <jnareb@xxxxxxxxx> 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.

At the moment there is no formal way for Git to record within the commit metadata the inclusion of the cherry-picked diff (the 'merge' of the fix).

Thinking out of the box, the issue is that the commit parents list does not have a formal mechanism to allow the recording that the 'merged' change was the patch change from a specific commit fom somewhere else (which may be missing from the local repo).

Perhaps it needs a style of merging-rebase where a second (last) parent is added but it isn't the straight <sha1>, but says 'patch-<sha1>', such that readers with the capability could check if that <sha1> history is present locally, and if so if it's correct, so that you can now 'track' your fixes between releases, and (hopefully) older Gits don't barf on that extra 'fake' parent. Somehow I suspect that older Git's would barf.. (not enough time to create and test such a fake commit)


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.

--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]