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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).