Jacob Keller [off-list ref] writes:
From: Jacob Keller <redacted>
The documentation for --refs says that it will treat unqualified refs as
under refs/notes. Current behavior is to prefix refs/notes to all
strings that do not start with refs/notes or notes/, resulting in
performing actions on refs such as "refs/notes/refs/foo/bar" instead of
attempting to perform actions on "refs/foo/bar".
That actually sounds like a sensible thing to do, if you replace
'foo' with 'heads', for example, i.e. refs/notes/refs/heads/bar is a
notes about commits reachable from the branch whose name is 'bar'.
So given "refs/heads/bar", which is unqualified in the context of
talking about references that hold notes trees, the current
behaviour to turn it into "refs/notes/refs/heads/bar" is very
sensible, I would think.
On Wed, Sep 16, 2015 at 3:34 PM, Junio C Hamano [off-list ref] wrote:
Jacob Keller [off-list ref] writes:
quoted
From: Jacob Keller <redacted>
The documentation for --refs says that it will treat unqualified refs as
under refs/notes. Current behavior is to prefix refs/notes to all
strings that do not start with refs/notes or notes/, resulting in
performing actions on refs such as "refs/notes/refs/foo/bar" instead of
attempting to perform actions on "refs/foo/bar".
That actually sounds like a sensible thing to do, if you replace
'foo' with 'heads', for example, i.e. refs/notes/refs/heads/bar is a
notes about commits reachable from the branch whose name is 'bar'.
So given "refs/heads/bar", which is unqualified in the context of
talking about references that hold notes trees, the current
behaviour to turn it into "refs/notes/refs/heads/bar" is very
sensible, I would think.
The end goal is to allow refs inside "refs/remote-notes/".. it seems
really weird that other fully qualified refs don't get "expanded" in
the same way as notes, and documentation does not make it explicit
that this is how it would work. I think that users who actually want
this behavior are already free to say "refs/notes/refs/heads/bar"...
that wouldn't change..
How would you propose allowing merging from "refs/remote-notes/<remote>/bar"?
We could easily just hard-code acceptance of refs/remote-notes/ as
well as refs/notes... But that felt weird to me...
But honestly I don't really care how it is done as long as we can "git
notes show", "git notes list" on refs/remote-notes/<origin>/commits
(or similar, remote-notes may not be the actual location if someone
came up with a better name?)
How would you propose we allow that?
If we keep the current behavior of "expand_notes_ref" then we
absolutely can't because use of "--ref" will auto expand
"refs/remote-notes/<origin>/commits" into
"refs/notes/refs/remote-notes/<origin>/commits" which wouldn't work...
Regards,
Jake
On Wed, Sep 16, 2015 at 3:34 PM, Junio C Hamano [off-list ref] wrote:
Jacob Keller [off-list ref] writes:
quoted
From: Jacob Keller <redacted>
The documentation for --refs says that it will treat unqualified refs as
under refs/notes. Current behavior is to prefix refs/notes to all
strings that do not start with refs/notes or notes/, resulting in
performing actions on refs such as "refs/notes/refs/foo/bar" instead of
attempting to perform actions on "refs/foo/bar".
That actually sounds like a sensible thing to do, if you replace
'foo' with 'heads', for example, i.e. refs/notes/refs/heads/bar is a
notes about commits reachable from the branch whose name is 'bar'.
So given "refs/heads/bar", which is unqualified in the context of
talking about references that hold notes trees, the current
behaviour to turn it into "refs/notes/refs/heads/bar" is very
sensible, I would think.
I never got any better suggestion on how to allow the behavior
desired, which is to enable merging from a non-notes location, in
order to provide a standard location for remote notes, ie:
refs/remote-notes/<remote>/<ref>
Any suggestions, if you're against this particular change?
Regards,
Jake