Re: git-note -C changes commit type?

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@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata@joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nomeata@debian.org