Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 12, 2015, 22:41 UTC
Message-ID: <xmqqmvxwjfjb.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CA+P7+xp0zhqM4CHmFpKuPyNMTx3DBxiLSOsiwz=byrfTEDj3sA@mail.gmail.com>

Jacob Keller <jacob.keller@gmail.com> writes:

> I spoke to soon. We have an "init_notes_check" function which shows
> that it does refuse to merge outside of refs/notes/* It prevents all
> notes operations outside of refs/notes

OK. Then it is OK to limit notes.<ref>.mergestrategy so that <ref> refers to what comes after refs/notes/, because we will not allow merging to happen outside the hierarchy.

If you are planning to break that promise, however, <ref> must be always spelled fully (i.e. with refs/notes/ prefix for those inside the hierarchy) to avoid ambiguity. Otherwise it will be hard to interpret a configuration that does something like this (note that these could come from multiple places, e.g. $HOME/.gitconfig and $GIT_DIR/config):

    [notes "commits"]
        mergestrategy = concatenate
    [notes "notes/commits"]
        mergestrategy = cat_sort_uniq
    [notes "refs/notes/commits"]
        mergestrategy = overwrite

The three entries in the above example obviously are all meant to refer to the same refs/notes/commits notes tree, and the usual "last one wins" rule should apply. But with the recent git_config_get_*() interface, you cannot tell which one among them was given the last, overriding the previous entries.