Re: git-note -C changes commit type?

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