Re: git-note -C changes commit type?

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

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

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
> <mail@joachim-breitner.de> wrote:
> > 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

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