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. > After all that setup, my question's simple. Does a `parent' in git > terminology simply mean `this commit was derived in some way from the > commit listed here'? When you think about commit ancestry, think of it this way: 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". 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. 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. 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. For example, if there is another topic forked off of B (or at a later commit from there that leads to 'latest'), after your "funny merge" took place, even the usual merge strategies would work as expected by you --- it would still ignore the changes up to B because you told git to do so. Also, if you make a good change on top of the resulting merge that _should_ be applicable to some-change-foo which is based on the 'latest', you cannot merge that back in the usual way. Usual git merge will find your first "funny merge" as the merge base, and because it chooses to reject everything leading to B, the merge result would look very similar to the set of changes based on old-and-grotty. Actually, that would even fast forward to the version you made into a phony "merge" out of the cherry-picked result. But that is at least consistent with the statement you made when you created that commit. Staying behind at old-and-grotty suited _your_ branch'es purpose better than being based on 'latest'. And a person who is merging _your_ branch into some-change-foo, by choosing to merge that branch into the latter, is choosing to share your branch'es purpose, so it is natural a lot of the "good things" that happened up to B is rewound by that merge. 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 ;-). - 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