On Fri, Jan 05, 2018 at 12:14:28PM -0800, Junio C Hamano wrote:
> Martin Fick <mfick@xxxxxxxxxxxxxx> 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.
> 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
