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 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).
