Junio C Hamano wrote: >>Aha, now I see reason in the madness. So, the "prior" head is not stored >>in the trees, and tracking the progress of actual head transitions is >>loosely defined / a research topic. But demonstrably derivable. That >>works for me. >> >> >I do not think there is any madness involved here, but I should > > Sorry, it was a figure of speech. It's more like, what appeared to be madness no longer looks so. >point out that the above example happens to work only because >Linus and David are two different people. If Linus did the >David's work in a separate repository, or even in the same >repository but on a separate branch, people following the Linus >tip might still want to know about the fast-forward, but that is >something you cannot truly tell by the digging like what I did >in the previous message. > >That is why I earlier said this: > > *1* IOW, we _are_ losing some information by not recording the > fact that fast-forward was done while doing so. > > That record should _not_ be in the commit chain. At the > mechanical level, recording that in the commit chain means two > criss-crossing branches never converge at the commit chain > level, which is already bad. > > Here I'm a little bit confused still. Surely criss-crossing branches already don't converge unless the commits are in the same order. Oh, I see. Even if they *are* in the same order, the commit IDs would end up different due to these extra headers. > At the philosophical level, the > commit chain is a mesh of many possible "global" histories, and > the record that somebody (a particular branch in a particular > repository) was at what point in the mesh at given time does not > belong there. > > But from the repository-owner's point of view, that _might_ be a > useful information to keep. I am just saying this preemptively > so that if somebody wants to record it, that should not be > recorded in the commit object. > > That makes sense. >On the other hand, a "note" field that records on which branch >of which repository each commit was made (you need to give each >repository-branch an UUID) when you do create a new commit would >be a sensible thing to have if somebody cares deeply enough. It >is an information that is global in nature, and with that, you >could do the digging like I did without relying on the committer >identity, but instead using the branch identity. > > That sounds reasonable. The UUID doesn't need to replicate, either, just tag the commits that were made against it. This extra information falls into the informational, "forensic" history tracing category. ie, we don't know now whether we'll need it, but we'll store it anyway just to be sure to not make later operations impossible. I think the large remaining question is around what conventions apply to the use of the "note" field. We have perhaps the first example of a well formed piece of "forensic" information that belongs in the commit chain and could possibly be added by plumbing. I can't think of any more of those, but the rename/copy tracking case is a bit different. In this case, it doesn't belong in the plumbing, yet you want a reasonable convention for storing this information to apply. Also the other cases outlined in the original post might do well to have a common convention so that the information is more portable between porcelain. Sam. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html