On 8 Nov 2006, Junio C. Hamano spake thusly: > Nix <nix@xxxxxxxxxxxxx> writes: > >> The idea being that if you have a tree like this: >> >> B >> ------------- ref trunks/latest >> \ >> ------ ref heads/some-change-foo >> >> ... -------- ref trunks/old-and-grotty >> >> >> then this merge strategy, when asked to merge heads/some-change-foo into >> trunks/old-and-grotty would spot that point B was the most recent >> merge point into anything in trunks/, generate a diff between point B >> and heads/some-change-foo, and patch it into trunks/old-and-grotty. > > This is a standard "cherry-picking" practice. Yes, pretty much, except that we do *everything* by cherry-picking, and we want to track the cherry-picks in the same way that all other changes are tracked (i.e., a small branch for each (numbered) change, patching madly in all directions into a variety of trunks and release branches, with all those patches tracked.) > These commits I list as its parents of this new commit, and > everything that leads to them, are what I considered when > derived this commit. This new child commit of them suits the > purpose of _my_ branch better than any of these parent > commits I took into consideration because of such and such > reasons that I stated in its commit log message. > > If you mark the resulting commit on old-and-grotty to have > some-change-foo as one of its parents, because some-change-foo > has almost everything 'latest' has (up to point B), you are also > saying "I have considered everything that happened between > old-and-grotty and B when making this commit". Yeah. This is the merge-base tracking that Linus mentioned, and it's not quite what I'm looking for :/ it's a sort of step-parent, really... > What's implied by that statement is this, even though you do not > explicitly say: > > I reject everything that happened on the development line > that led to 'latest' up to point B since old-and-grotty was > forked. (which is not necessarily true: we might want to backport an earlier change, also on another `small change branch', later on. Stuff on the trunks themselves will never want to get backported, but if the merge-base algorithm traverses patch-merge parent links, it might consider that a `small change branch' has been merged when it actually hasn't.) > This is not necessarily a bad thing, by the way. For somebody > who is trying to maintain extremely-stable branch by cherry > picking only changes in a few narrow areas from the mainline > would _want_ to leave most of the "new good stuff" out from his > branch. That's why I emphasized _my_ a few paragraphs above. That's exactly what we're doing, across-the-board. > But it is _so_ different from the mindset of usual "every branch > makes progress _forward_ perhaps with different pace". In this > example, this branch is actively choosing to stay behind and > refusing to take changes from the 'latest'. So your users need > to really understand what they are doing. *hahahaaaaa*... hang on, that *was* a joke, right? ;) > So I think as long as you and your users understand what is > going on, I do not see a problem at either the mechanical level > or the philosophical level. But I am sure it would confuse a > lot of people, so please do not come back complaining that you > ended up getting your users heads explode ;-). OK, I think I need to find a way to notate in the patch-merged commit that one or more parents should be disregarded when searching for merge bases (and *only* when searching for merge bases). I think that will do what's wanted in all areas: i.e., it'll act like a cherry-pick that shows up in the logs/revlist and so on, but doesn't affect the semantics of later merges of stuff from anywhere except for the same limited branch. (obviously trying to patch-merge B to A twice is always going to fail, whether or not merge-base traversal jumps into B: I don't think there's any real need to protect against that.) -- Rich industrial heritage: lifeless wasteland. `The land north of Mordor has a rich industrial heritage.' - 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