Re: [PATCH] technical doc: add a design doc for the evolve command

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 19, 2018, 02:15 UTC
Message-ID: <xmqqftvxertd.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAPL8Zisv-Q04Y_jQzMN7G9fG9rkWwxh4travnSw6cG0ZUFivkA@mail.gmail.com>

Stefan Xenos <sxenos@google.com> writes:

Show 10 quoted lines

>> 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.