Re: [PATCH] technical doc: add a design doc for the evolve command
- Date: Mon, 19 Nov 2018 11:15:10 +0900
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH] technical doc: add a design doc for the evolve command
Stefan Xenos <sxenos@xxxxxxxxxx> writes:
>> And the other half is that while I consider the "origin" thing is
>> unnecessary for the above reasons, having it means we need to not
>> just transfer the history reading to aa7ce555 and d664309ee (which
>> are necessary anyway while we have histories to transplant from
>> d664309ee to aa7ce555) but also have to pull in the history leading
>> to 7e1bbcd and we cannot discard it.
> I'll assume that by "history" you're referring to the change graph
> (the metacommits) and not the branches (the commits), which would have
> no origin edges or connection between replacements.
I meant the project's history, not the meta-graph thing.
By having a "this was cherry-picked from that commit" in a commit
that is not GC'ed, the original commit that has no longer have any
relevance (because the newer one that is the result of the
cherry-pick is the surviving version people will be building on) is
kept reachable. It is very much delierate that "cherry-pick -x"
does not make the "origin" reachable and merely notes it in the
human readable form that is ignored by the reachablity machinery.
> If the user has kept a change around in their metas namespace, it's an
> indication that they (or their collaborators) are still working on it
> and want its history to be retained.
This is where we differ. If commit X was rewritten (perhaps with
help from change cherry-picked from commit Z, or without any) to
produce Y, I do agree that it would be logical to keep X around
until every dependent commit on it are migrated to be on top of Y.
But we do not need Z to transplant what used to be on X on top of Y,
do we? So I do agree that in such a situation they want the
relevant parts of the history retained, but I do not agree that
"origin" is among them.
Side note. As long as we have commits yet to be migrated to
be on Y that still is on X, ew do not need the meta-commit
to be protecting from getting GC'ed, as X is reachable from
these "need to be updated" branch tips anyway. What we gain
from extra reachability brought in by the meta commits is
that by fetching the "change", we get Y (and its anestors),
even if we are not following any branch that contains it, so
that we can migrate those that are still based on X to it.