Re: Bring together merge and rebase

From: Carl Baldwin <carl@ecbaldwin.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Bring together merge and rebase
Date: Tue, 26 Dec 2017 12:44:09 -0700	[thread overview]
Message-ID: <20171226194408.GA22855@Carl-MBP.ecbaldwin.net> (raw)
In-Reply-To: <87vagtqszf.fsf@evledraar.gmail.com>

On Tue, Dec 26, 2017 at 06:49:56PM +0100, Ævar Arnfjörð Bjarmason wrote:
> New headers should be added after existing headers, but other than
> that it won't choke on it. See 4b2bced559 when the encoding header was
> added, this also passes most tests:
> 
>     diff --git a/commit.c b/commit.c
>     index cab8d4455b..cd2bafbaa0 100644
>     --- a/commit.c
>     +++ b/commit.c
>     @@ -1565,6 +1565,8 @@ int commit_tree_extended(const char *msg, size_t msg_len,
>             if (!encoding_is_utf8)
>                     strbuf_addf(&buffer, "encoding %s\n", git_commit_encoding);
> 
>     +       strbuf_addf(&buffer, "replaces 0000000000000000000000000000000000000000\n");
>     +
>             while (extra) {
>                     add_extra_header(&buffer, extra);
>                     extra = extra->next;
> 
> Only "most" since of course this changes the sha1 of every commit git
> creates from what you get now.
> 
> > Even if core git code does not simply choke on it, I would like push and
> > pull to follow these pointers and transfer the history behind them. I
> > assumed that git would not do this today. I would also like gc to
> > preserve e8aa79baf6 as if it were referenced by a parent pointer so that
> > it doesn't purge it from the history.
> 
> It won't pay any attention to them if "replaces" is something entirely
> new, what I was pointing out in my earlier reply is that you can simply
> *also* create the parent pointers to these no-op merge commits that hide
> away the previous history the "replaces" headers will be referencing.
> 
> The reason to do that is 100% backwards compatibility, and and only
> needing to make minor UI changes to have this feature (to e.g. history
> walking), as opposed to needing to hack everything that now follows
> "parent" or constructs a commit graph.

Thank you for clarifying this. I have learned something.

> Sure, it could be opt in, be a new format etc. But you haven't
> explained why you think a feature like this would need to rely on an
> entirely new parent structure and side-DAG, as opposed to just the
> more minor changes I'm pointing out above, and which I think will give
> you what you need from a UX level.

I have not wrapped my head around it enough to convince myself that it
gives what I'm after. Let me spend a little more time with it to get a
feel for it.

Carl