Sebastian Schuberth <[email protected]> writes:
> Signed-off-by: Sebastian Schuberth <[email protected]>
> ---
> Documentation/git-notes.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
> index 8de3499..5375d98 100644
> --- a/Documentation/git-notes.txt
> +++ b/Documentation/git-notes.txt
> @@ -234,8 +234,9 @@ which operation triggered the update, and the commit
> authorship is
> determined according to the usual rules (see linkgit:git-commit[1]).
> These details may change in the future.
>
> -It is also permitted for a notes ref to point directly to a tree
> -object, in which case the history of the notes can be read with
> +It is also permitted for a notes ref to point to any other object in
> +the object store besides commit objects, that is annotated tags, blobs
> +or trees. For the latter, the history of the notes can be read with
> `git log -p -g <refname>`.
I do not think this is correct place to patch. The original is not
talking about what objects can have notes attached at all. What it
explains is this.
<refname> aka refs/notes/<name> (where <name> typically is
"commit") is usually a commit, whose tree is a notes-shaped
tree. The (normal) history you get by following the parent link
of the commit represents how the entire set of notes evolved.
However, it is OK for the <refname> to point directly to a tree,
which is a notes-shaped one, without an enclosing commit. You
would lose the normal way to learn how the entire set of notes
evolved, but you could do "git log -p -g <refname>", i.e. by
following its reflog, to pretend as if the history is recorded.
There is no way a blob can be pointed by <refname> there and expect
it to work sensibly at all.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
