Dear Johan, thanks for the patch! Am Mittwoch, den 12.02.2014, 11:26 +0100 schrieb Johan Herland: > Here's another way to solve your problem, which should be fairly > transparent and performant: > > Whenever you want to reference "history" of a commit (I'm using quotes > here, because we're not talking about the "regular" git sense of > history, i.e. the commit graph), you perform the following two steps: > > 1. Append the "historical" commit SHA-1 (3d7de37 in your example) to a > note on the "current" commit (e1bfac4). E.g.: > > git notes --ref history append -m 3d7de37... e1bfac4... > > 2. Perform some automated merge into a "history"-tracking ref (e.g. > refs/history), to keep the "historical" commits reachable. > > (You can easily wrap both steps into a script to automate things.) > > Step #1 encodes the "history" of a commit in a note, but does not keep > the "history" reachable. > > Step #2 keeps all "historical" commits reachable by making them part > of the history (in the git sense - without quotes) of a proper ref > (refs/history). The actual result/outcome of the merge is not > interesting. It only exists to insert the "historical" commit > (3d7de37) into the ancestry for refs/history. Since the actual merge > itself is uninteresting, you should probably use a merge strategy that > never yields conflicts, e.g. "-s ours" > > You can now share the "history" by pushing/fetching the two refs > refs/notes/history and refs/history. > > (In theory, you might even be able to combine the two refs, by > performing the merge directly into refs/notes/history, always taking > care to retain the notes tree contents as the result of the merge. In > other words, after you do step #1 (append the note), you manually > rewrite the just-created tip of refs/notes/history to include 3d7de37 > as a second parent. This keeps 3d7de37 reachable (and it will be > shared when you share refs/notes/history), and it should not interfere > with the notes infrastructure, as they only look at the current state > of the notes tree.) That is quite a good approximation. What it doesn’t do is dropping history (in the refs/history sense) of commits that disappear, but the same problem exists with notes. Thanks! I guess there are no plans to make the commit object format itself extensible, are they? Extensible in the sense that I can add a custom field to it (e.g. history:). Git would not have to know anything about the field besides its type, i.e. that it contains refs that it has to follow. Very much like "parent:", just without the semantics of it wrt. "git log" and the like. Greetings, Joachim -- Joachim “nomeata” Breitner mail@xxxxxxxxxxxxxxxxxxx • http://www.joachim-breitner.de/ Jabber: nomeata@xxxxxxxxxxxxxxxxxxx • GPG-Key: 0x4743206C Debian Developer: nomeata@xxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part