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

Nix [off-list ref] 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 ;-).