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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Adam Spiers <git@xxxxxxxxxxxxxx> writes:

>     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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]