Re: Bring together merge and rebase
- From
- Carl Baldwin <carl@ecbaldwin.net>
- Date
- Dec 26, 2017, 19:44 UTC
- Message-ID
- <20171226194408.GA22855@Carl-MBP.ecbaldwin.net>
- In-Reply-To
- <87vagtqszf.fsf@evledraar.gmail.com>
On Tue, Dec 26, 2017 at 06:49:56PM +0100, Ævar Arnfjörð Bjarmason wrote:
Show 36 quoted lines
> 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.
Show 5 quoted lines
> 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