git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.



	

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