From: Junio C Hamano <gitster@pobox.com>
To: Stefan Xenos <sxenos@google.com>
Cc: git@vger.kernel.org
Subject: Re: Git Evolve
Date: Sat, 29 Sep 2018 17:55:56 -0700 [thread overview]
Message-ID: <xmqqbm8f952b.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAPL8ZivFmHqS2y+WmNR6faRMnuahiqwPVYsV99NiJ1QLHOs9fQ@mail.gmail.com> (Stefan Xenos's message of "Sat, 29 Sep 2018 16:00:04 -0700")
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.
[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.
next prev parent reply other threads:[~2018-09-30 0:57 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 [this message]
2018-09-30 20:17 ` Stefan Xenos
2018-10-04 16:05 ` Jakub Narebski
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
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=xmqqbm8f952b.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--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).