Re: Bring together merge and rebase

From: Carl Baldwin <carl@ecbaldwin.net>
Date: Dec 28, 2017, 05:23 UTC
Message-ID: <20171228052303.GA33027@Carl-MBP>
In-Reply-To: <C82A30ED-D608-4F79-B824-C23DDB078DD9@gmail.com>

On Wed, Dec 27, 2017 at 03:35:58PM +0200, Alexei Lozovsky wrote:

Show 14 quoted lines

> I think the reasoning behind Theo's words is that it would be better
> to first implement the commit relationship tracking as an add-in which
> uses commit messages for data storage, then evaluate its usefulness
> when it's actually available (including extensions to gitk and stuff
> to support the new metadata), and then it could be moved into core git
> data structures, when it has proven itself useful. It's not a trivial
> feature which warrants immediate addition to git and its design can
> change when faced with real- world use-cases, so it would be bad for
> compatibility to rush its addition. Storage location for metadata
> seems to be an implementation detail which could be technically
> changed more or less easily. But it's much easier to ignore a trailer
> in commit message in the favor of a commit header field than to
> replace a deprecated commit header field with a better one, which
> could cause massive headache for all git repositories in the world.

Yeah, this is a point that everyone is eager to make instead of really trying to understand what I'm trying to do and offering constructive suggestions. It's not that I'm not listening. I'm not really concerned about headers vs trailers or the asthetics of the whole thing as much as I'm concerned about how the server / client interaction will be. I worry that anything that I come up with that isn't implemented in the regular git core push and fetch will end up being awkward or end up needing to reimplement a lot of what's already in git. But, maybe it just needs a little more thought. Let me try to think through it...

Imagine John posts a new change up for review to a review server. The current master points at commit A and so he grabs it and drafts his first proposal, B1.

    digraph history {
        B1 -> A
    }

Soon after posting, he notices a couple of simple errors and uses the web UI to correct them. This creates B2. (Dashed edges are replaces references).

    digraph history {
        B1 -> A
        B2 -> A
        B2 -> B1 [ style="dashed"; ]
    }

Anna reviews B2 and finds a small nit. She asks John if she can just fix it and push up a new review. He agrees. She pushes up B3.

    digraph history {
        B1 -> A
        B2 -> A
        B3 -> A
        B2 -> B1 [ style="dashed"; ]
        B3 -> B2 [ style="dashed"; ]
    }

John goes back to his workspace and does a little more work on B. He creates the fourth revision, B4 but since he didn't update his workspace with the other two most recent revisions, his new revision is derived from B1.

    digraph history {
        B1 -> A
        B2 -> A
        B3 -> A
        B4 -> A
        B2 -> B1 [ style="dashed"; ]
        B3 -> B2 [ style="dashed"; ]
        B4 -> B1 [ style="dashed"; ]
    }

John then pushes to the server. I imagined that would be a command similar to what gerrit does.

    git push codereview refs/for/master

At this point, I want a couple of things to happen. First, the server should be able to match the new revision to the change by following the replaces references to the commits it already has. Then it should recognize that this is not a fast forward update to the change and reject it on those grounds.

After that, John needs to be able to fetch B2 and B3 so that his local client can perform a merge. I guess John needs to know what change he's trying to fetch. In this case, he needs to fetch both B2 and B3 in order get the full history graph of the change. The problem I see here is that today's git fetch would see B2 and B3 as unrelated branches. There could be any number of them to fetch. So, how does he ask for everything related to the change? Does he do a wild card or something?

    git fetch codereview refs/changes/123/*

Or does he just fetch all refs (this could be many on a busy review server)? Or do we need to do something out of band to discover the list of references that need to be fetched?

I've been thinking out loud a bit. I guess this could be a path forward. I guess to make gc happy, I've got to keep around a ref pointing at each new revision so that it doesn't get garbage collected.

Carl