On Fri, 12 Sep 2008, Sam Vilain wrote:Actually, don't make it dependent on merge conflicts. Just make it depend on whether the patch ID is _different_. It can happen even without any conflicts, just because the context changed. So it really isn't about merge conflicts per se, just the fact that a patch can change when it is applied in a new area with a three-way diff - or because it got applied with fuzz. You could add it as a Original-patch-id: <sha1> or something. And then you just need to teach "git cherry/rebase" to take both the original ID and the new one into account when deciding whether it has already seen that patch. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Jeff Chua | 2.6.27rc1 cannot boot more than 8CPUs |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Winkler, Tomas | RE: iwlwifi: fix build bug in "iwlwifi: fix LED stall" |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Andrew Dickinson | tx queue hashing hot-spots and poor performance (multiq, ixgbe) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
