Re: Bring together merge and rebase

From: Carl Baldwin <carl@ecbaldwin.net>
Date: Jan 6, 2018, 17:29 UTC
Message-ID: <20180106172919.GA17272@Carl-MBP.ecbaldwin.net>
In-Reply-To: <xmqq4lo0cbbv.fsf@gitster.mtv.corp.google.com>

On Fri, Jan 05, 2018 at 12:14:28PM -0800, Junio C Hamano wrote:

Show 17 quoted lines

> Martin Fick <mfick@codeaurora.org> writes:
> 
> > These scenarios seem to come up most for me at Gerrit hack-
> > a-thons where we collaborate a lot in short time spans on 
> > changes.  We (the Gerrit maintainers) too have wanted and 
> > sometimes discussed ways to track the relation of "amended" 
> > commits (which is generally what Gerrit patchsets are).  We 
> > also concluded that some sort of parent commit pointer was 
> > needed, although parent is somewhat the wrong term since 
> > that already means something in git.  Rather, maybe some 
> > "predecessor" type of term would be better, maybe 
> > "antecedent", but "amended-commit" pointer might be best?
> 
> In general, I agree that you would want richer set of "relationship"
> than mere "predecessor" or "related", but I do not think "amended"
> is sufficient.  I certainly do not think a "pointer" embedded in a
> commit object is a good idea, either (a new commit object header is

To me, this is roughly equivalent to saying that parent pointers embedded in a commit object is a good idea because we want a richer relationship than mere "parent". Look how much we've done with this simple relationship. Similarly, the new relationship that I'm proposing handles much more than the simple m==n==1 case. Read below for more detail.

Show 16 quoted lines

> out of question, but I doubt it is a good idea to make a pointer
> back to an existing commit as a part of the log message).
> 
> You may used to have a set of n-patches A1, A2, ..., An, that turned
> into m-patches X1, X2, ..., Xm, after refactoring.  During the work,
> it may turned out that some things the original tried to do are not
> sensible and dropped, while some other things are added in the final.
> series.  
> 
> When n==m==1, "amended" pointer from X1 to A1 may allow you to
> answer "Is this the first attempt?  If this is refined, what did the
> earlier one look like?" when given X1, but you would also want to
> answer a related question "This was a good start, but did the effort
> result in a refined patch, and if so what is it?" when given A1, and
> "amended" pointer won't help at all.  Needless to say, the "pointer"
> approach breaks down when !(n==m==1).

It doesn't break down. It merely presents more sophisticated situations that may be more work for the tool to help out with. This is where I think a prototype will help see these situations and develop the tool to manage them.

When each of n commits is amended or rebased trivially into m==n new commits then each change is represented by a distinct graph of predecessors that can be followed independently of others. With rebase, this is accomplished by using only "pick" in interactive mode or not using interactive mode at all (and no autosquash).

The more sophisticated cases can be broken down into two operations that change the number of resulting commits.

  1. Squashing two commits together ("fixup", "squash"). In this case,
     the resulting commit will have two or more pointers. This clearly
     shows that multiple changes converged into one at this point.

  2. Splitting a single commit into multiple new commits ("edit"). In
     this case, the graph shows multiple new commits pointing to the
     same predecessor. In my experience, this is less common. It also is
     a little more challenging to think about the tool managing
     divergent work but I think it is possible.

The end result is m commits where m can be any positive number (even, coincidentally, n). However, the graph of amended commits still tells the story quite well. Even if commits are reordered, the graphs can still be useful. The predecessor graph is independent of the parent graph which makes up normal git commit history so it isn't inherently bad that the order of commits was changed.

We can dream up some very interesting graphs. Sure, as we do increasingly more complicated history rewriting, it is going to be increasingly more difficult for the tool to help out. I'm not really deterred by this at this point. I want to experiment and work it out with a prototype.

My primary objective personally is to detect where work on a single change has diverged by working on it from more than one workspace whether its multiple people chipping in or just me. Merely having the ability to reject an update that clobbers divergent work is a big win. No more silent corruption of work.

My secondary objective is to develop a tool to help get the divergent work back on track. I believe that in the majority of common cases, this tool can be successful in either finding an automatic way to bring the divergent work back into a new revision of the change or present the user with conflicts to resolve that end up being much easier than what I've had to do in past experience with rebase workflows.

Carl