Re: git-note -C changes commit type?

From: Joachim Breitner <mail@joachim-breitner.de>
Date: Feb 12, 2014, 08:53 UTC
Message-ID: <1392195218.2546.7.camel@kirk>
In-Reply-To: <CALKQrgcM7JpZCk4amjo_rwg5uuuWNg-5yd1NXB5p7EtrU9WBGg@mail.gmail.com>

Dear Johan,

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

Show 8 quoted lines

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

Show 16 quoted lines

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

Show 5 quoted lines

> 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