Re: improvements to checks for core.notesRef / GIT_NOTES_REF / --ref

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2013, 17:13 UTC
Message-ID: <7vmwshjm4j.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130429163909.GA19014@pacific.linksys.moosehall>

Adam Spiers <git@adamspiers.org> writes:

Show 8 quoted lines

>     static struct notes_tree *init_notes_check(const char *subcommand)
>     ...
> Can we relax this to "refs/", to allow better isolation of namespaces
> for remote notes?  Also, the check is applied for GIT_NOTES_REF and
> core.notesRef, but not for values passed via --ref.  Therefore I would
> propose that init_notes_check() is not only relaxed but also moved
> from builtin/notes.c to notes.c, so that it can be consumed by
> default_notes_ref().  Thoughts?

Such a policy decision at the application level should be done in builtin/notes.c, and not notes.c, I think. It is OK to have a sharable check routine in notes.c and help different notes applications to implement their own sanity checking, though. "git notes" that operates only on local notes might restrict its operation to refs/notes, while "git notes-merge" may allow it to read from other hierarchies but still write only into refs/notes, for example.

I am not sure if it is a good idea in general to have a separate remotes-notes/ hierarchy in the first place, though. Wouldn't the notes be less like branches (private view) and more like tags (common world view)?

> Also, are there any plans in the future for making "git notes merge"
> provide an index, so that a proper 3-way merge with ancestor can be
> done using git mergetool?

Are we committed that all notes leaves must be blobs (I do not personally mind it)?

I do think we need a way to call a custom low level 3-way merge driver once we identify which notes blobs correspond to each other with what common ancestor notes blob while merging two notes trees.

But I do not think that "an index" that we use for the usual working tree merge is necessarily a good representation for driving such a ll-merge driver and recording its result. Each side likely has a note for the same object to be merged in a different fan-out layout, and fan-out is merely a performance hack to spread the objects in smaller trees. As mergetools only work with the usual working tree with the usual index, they may be a poor substitute for ll-merge drivers to handle merging notes trees.