From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Xenos <sxenos@google.com>, git@vger.kernel.org
Subject: Re: Git Evolve
Date: Thu, 04 Oct 2018 18:05:10 +0200 [thread overview]
Message-ID: <86d0spzoi1.fsf@gmail.com> (raw)
In-Reply-To: <xmqqbm8f952b.fsf@gitster-ct.c.googlers.com> (Junio C. Hamano's message of "Sat, 29 Sep 2018 17:55:56 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Stefan Xenos <sxenos@google.com> writes:
>
>> What is the evolve command?
>> ...
>> - Systems like gerrit would no longer need to rely on "change-id" tags
>> in commit comments to associate commits with the change that they
>> edit, since git itself would have that information.
>> ...
>> Is anyone else interested in this? Please email me directly or on this
>> list. Let's chat: I want to make sure that whatever we come up with is
>> at least as good as any similar technology that has come before.
>
> As you listed in the related technologies section, I think the
> underlying machinery that supports "rebase -i", especially with the
> recent addition of redoing the existing merges (i.e. "rebase -i
> -r"), may be enough to rewrite the histories that were built on top
> of a commit that has been obsoleted by amending.
>
> I would imagine that the main design effort you would need to make
> is to figure out a good way to
>
> (1) keep track of which commits are obsoleted by which other ones
> [*1*], and
>
> (2) to figure out what histories are still to be rebuilt in what
> order on top of what commit efficiently.
>
> Once these are done, you should be able to write out the sequence of
> instructions to feed the same sequencer machinery used by the
> "rebase -i" command.
Well, that assumes that "rebase -i" can correctly recreate merges, if
needed.
> [Side note]
>
> *1* It is very desirable to keep track of the evolution of a change
> without polluting the commit object with things like Change-Id:
> and other cruft, either in the body or in the header. If we
> lose the Change-Id: footer without adding any new cruft in the
> commit object header, that would be a great success. It would
> be a failure if we end up touching the object header.
Doesn't Gerrit use git-notes instead of 'Change-Id:' trailer nowadays?
Notes transport is quite easily controlled; the problem with notes merge
does not matter for this use.
Best,
--
Jakub Narębski
next prev parent reply other threads:[~2018-10-04 16:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-29 23:00 Git Evolve Stefan Xenos
2018-09-30 0:55 ` Junio C Hamano
2018-09-30 20:17 ` Stefan Xenos
2018-10-04 16:05 ` Jakub Narebski [this message]
2018-10-04 17:29 ` Stefan Xenos
2018-10-01 12:37 ` Derrick Stolee
2018-10-31 21:12 ` Stefan Xenos
2018-10-02 1:23 ` Taylor Blau
2018-10-02 9:11 ` Ævar Arnfjörð Bjarmason
2018-10-02 19:35 ` Stefan Xenos
2018-10-02 22:25 ` Kyle Meyer
2018-10-02 23:09 ` Taylor Blau
2018-11-09 13:06 ` Johannes Schindelin
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=86d0spzoi1.fsf@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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 NNTP newsgroup(s).