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

[Nix <nix@esperi.org.uk>]

On 8 Nov 2006, Junio C. Hamano spake thusly:
> Nix <nix@esperi.org.uk> 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