Re: git-note -C changes commit type?

Dear Johan,

Am Mittwoch, den 12.02.2014, 00:52 +0100 schrieb Johan Herland:

On Tue, Feb 11, 2014 at 6:23 PM, Joachim Breitner
[off-list ref] wrote:

quoted

judging from the documentation I got the impression that I can pass any
git object has to "git note -C <hash>" and it would stored as-is. But it
seems the objects gets mangled somehow...

...well... the documentation does not say "any object", it actually
explicitly says "blob object"... ;)

ok, my bad; guess I’m not fully versed with gits terminology.

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? 

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

Greetings,
Joachim

¹ I’m not proposing for anyone else but me to use this, at the moment,
don’t worry :-). But I am considering to use it in the context of GHC,
which isn’t a small project either.

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