Re: What's the meaning of `parenthood' in git commits?

On 8 Nov 2006, Junio C. Hamano spake thusly:

Nix [off-list ref] writes:

quoted

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