Re: git-note -C changes commit type?

[Joachim Breitner <mail@joachim-breitner.de>]

[-- Attachment #1: Type: text/plain, Size: 2903 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]