Re: git-note -C changes commit type?

[Johan Herland <johan@herland.net>]

On Wed, Feb 12, 2014 at 9:53 AM, Joachim Breitner
<mail@joachim-breitner.de> wrote:
> Am Mittwoch, den 12.02.2014, 00:52 +0100 schrieb Johan Herland:
>> You would have a notes ref "refs/notes/history" whose tree would
>> contain an entry named e1bfac434ebd3135a3784f6fc802f235098eebd0
>> pointing to a _commit_ (3d7de37...). Obviously, it would not make
>> sense to use refs/notes/history while displaying the commit log ("git
>> log --notes=history"), as the raw commit object would be shown in the
>> log. However, more fundamentally: a tree referring to a _commit_ is
>> usually how Git stores _submodule_ links (i.e. which revision of the
>> named submodule is to be used by this super-repo tree), and I'm (off
>> the top of my head) not at all sure that such a submodule link in a
>> notes tree is handled "sanely" by Git - or even that it makes sense at
>> all. For one, I'm not sure that Git requires (or even expects) the
>> commit object referenced by a tree to be present in the same object
>> DB. So if you share your notes, I don't know whether or not the
>> fetch/push machinery will include the commit object in the shared
>> notes... These are questions that should be answered before we decide
>> whether using commits directly as notes makes sense.
>
> If that is the case, then my approach is indeed flawed. The main point
> of the exercise is to have a tree that follows another commit (or, as a
> next-best approximation, a note attached to that commit) around.
>
>> In that case, you might be better off using an explicit
>> ref to keep that history alive; e.g. you could create
>> refs/history/e1bfac4 to point to 3d7de37 ("git update-ref
>> refs/history/e1bfac4 3d7de37"), and keep everything
>> alive/reachable/shareable that way...
>
> That’s an interesting idea; instead of relying on the notes feature
> putting the hash in the ref name. But I wonder how that scales – imagine
> every second feature merged into Linux¹ also having such a history ref?

Ah, that will probably not scale very well.

> I guess having a way for a tree to reference commits in a way that is
> followed by git gc, i.e. separate from submodules, would allow a less
> noisy implementation, and possibly create the opportunity for many other
> strange uses of git :-)

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


Hope this helps,

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net