From: Junio C Hamano <gitster@pobox.com>
To: Stefan Xenos <sxenos@google.com>
Cc: git@vger.kernel.org, Stefan Beller <sbeller@google.com>,
Jonathan Nieder <jrn@google.com>, Junio C Hamano <jch@google.com>,
Jonathan Tan <jonathantanmy@google.com>,
Derrick Stolee <stolee@gmail.com>,
Carl Baldwin <carl@ecbaldwin.net>,
Dave Borowitz <dborowitz@google.com>
Subject: Re: [PATCH] technical doc: add a design doc for the evolve command
Date: Mon, 19 Nov 2018 11:15:10 +0900 [thread overview]
Message-ID: <xmqqftvxertd.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAPL8Zisv-Q04Y_jQzMN7G9fG9rkWwxh4travnSw6cG0ZUFivkA@mail.gmail.com> (Stefan Xenos's message of "Sun, 18 Nov 2018 16:36:43 -0800")
Stefan Xenos <sxenos@google.com> 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.
next prev parent reply other threads:[~2018-11-19 2:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 0:55 [PATCH] technical doc: add a design doc for the evolve command sxenos
2018-11-15 12:52 ` Johannes Schindelin
2018-11-17 20:30 ` Stefan Xenos
2018-11-19 15:55 ` SZEDER Gábor
2018-11-19 21:32 ` Stefan Xenos
2018-11-20 1:09 ` Jonathan Nieder
2018-11-15 15:36 ` Ævar Arnfjörð Bjarmason
2018-11-20 1:18 ` Jonathan Nieder
2018-11-20 9:43 ` Ævar Arnfjörð Bjarmason
2018-11-20 17:45 ` Stefan Xenos
2018-11-20 22:06 ` Jonathan Nieder
2018-11-20 23:45 ` Stefan Xenos
2018-11-21 1:33 ` Jonathan Nieder
2018-11-21 19:10 ` Stefan Xenos
2018-11-16 21:36 ` Derrick Stolee
2018-11-17 23:44 ` Stefan Xenos
2018-11-17 6:06 ` Duy Nguyen
2018-11-18 22:27 ` Stefan Xenos
2018-11-18 22:29 ` Stefan Xenos
2018-11-18 23:20 ` Junio C Hamano
2018-11-17 7:36 ` Junio C Hamano
2018-11-19 0:36 ` Stefan Xenos
2018-11-19 2:15 ` Junio C Hamano [this message]
2018-11-19 3:33 ` Stefan Xenos
2018-11-19 3:45 ` Junio C Hamano
2018-11-19 4:15 ` Junio C Hamano
2018-11-19 20:14 ` Stefan Xenos
2018-11-19 20:26 ` Jonathan Nieder
2018-11-20 1:03 ` Junio C Hamano
2018-11-20 17:27 ` Stefan Xenos
2018-11-20 12:18 ` Phillip Wood
2018-11-20 12:59 ` Phillip Wood
2018-11-20 20:19 ` Stefan Xenos
2019-01-15 11:16 ` Phillip Wood
2018-11-20 13:03 ` Phillip Wood
2018-11-20 20:24 ` Stefan Xenos
2018-11-21 12:14 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqftvxertd.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=carl@ecbaldwin.net \
--cc=dborowitz@google.com \
--cc=git@vger.kernel.org \
--cc=jch@google.com \
--cc=jonathantanmy@google.com \
--cc=jrn@google.com \
--cc=sbeller@google.com \
--cc=stolee@gmail.com \
--cc=sxenos@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.