Shawn Pearce [off-list ref] writes:
On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano [off-list ref] wrote:
quoted
Shawn Pearce [off-list ref] writes:
quoted
quoted
But really, aside from slightly helping
disambiguate references from paths in the command line, what is it good
for?
Nothing really; today refs/ prefix is used to encourage to the tools
that you really meant refs/heads/master and not
refs/heads/heads/master or some other crazy construct. You can thank
the DWIMery inside the ref rev parse logic for needing this.
Aren't you two forgetting one minor thing, though?
A layout without refs/, i.e. $GIT_DIR/{heads,tags,...}, will force
us to keep track of where the tips of histories are anchored for
reachability purposes, every time you would add a new hierarchy
(e.g. $GIT_DIR/changes)--and those unfortunate souls who run a
slightly older version of Git that is unaware of 'changes' hierarchy
would weep after running "git gc", no?
You still store them under refs/
Well I know; the comment was merely a reaction to the exchange
between you two, "What is refs/ good for?", "Nothing really".
You'd benefit by having "refs/" that is known to contain all the
anchoring points for reachability without knowing what subhierarchy
it may contain in the future, that is what it is good for.
On 12/22/2015 08:34 PM, Junio C Hamano wrote:
Shawn Pearce [off-list ref] writes:
quoted
On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano [off-list ref] wrote:
quoted
Shawn Pearce [off-list ref] writes:
quoted
quoted
But really, aside from slightly helping
disambiguate references from paths in the command line, what is it good
for?
Nothing really; today refs/ prefix is used to encourage to the tools
that you really meant refs/heads/master and not
refs/heads/heads/master or some other crazy construct. You can thank
the DWIMery inside the ref rev parse logic for needing this.
Aren't you two forgetting one minor thing, though?
A layout without refs/, i.e. $GIT_DIR/{heads,tags,...}, will force
us to keep track of where the tips of histories are anchored for
reachability purposes, every time you would add a new hierarchy
(e.g. $GIT_DIR/changes)--and those unfortunate souls who run a
slightly older version of Git that is unaware of 'changes' hierarchy
would weep after running "git gc", no?
You still store them under refs/
Well I know; the comment was merely a reaction to the exchange
between you two, "What is refs/ good for?", "Nothing really".
You'd benefit by having "refs/" that is known to contain all the
anchoring points for reachability without knowing what subhierarchy
it may contain in the future, that is what it is good for.
You are answering "What is 'refs/' good for in the pathnames of files
that store loose references?" I was asking "What is 'refs/' good for in
the logical names of references?"
It would have been totally possible to make the full name of a branch
be, for example, "heads/master" and nevertheless store its loose
reference in "$GIT_DIR/refs/heads/master". The obvious place to store
HEAD in such a scheme would have been "$GIT_DIR/refs/HEAD" while still
calling it "HEAD". This could have avoided the problem that we now have
with pseudo-references like FETCH_HEAD being stored directly in $GIT_DIR.
On 12/22/2015 09:56 PM, Martin Fick wrote:
On Tuesday, December 22, 2015 06:17:28 PM you wrote:
quoted
On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty
[off-list ref] wrote:
quoted
[...] Would we really be worse off if
references' full names were
HEAD
heads/master
tags/v1.0.0
remotes/origin/master (or remotes/origin/heads/master)
I think this is a bit off, because
HEAD != refs/HEAD
so not quite useless.
A reference called "refs/HEAD" is not forbidden today but it's still not
very useful, is it? Do you know of some system that uses reference names
like this or are you just pointing out that it's theoretically possible?
But, I agree that the whole refs notation has always bugged
me, it is quirky. It makes it hard to disambiguate when
something is meant to be absolute or not. What if we added
a leading slash for absolute references? Then I could do
something like:
/HEAD
/refs/heads/master
/refs/tags/v1.0.0
/refs/remotes/origin/master
I like the idea of having a way to express "absolute" reference names.
But maybe if we do so we could take a step towards deprecating "refs/"
in references' logical names, by instead using the following absolute
notation for the above references:
/HEAD
/heads/master
/tags/v1.0.0
/remotes/origin/master
Specifically:
* Any name of the form "/$name" for which is_pseudoref_syntax($name)
returns true would be mapped to what we today call "$name" (e.g.,
"/FETCH_HEAD" would be mapped to today's "FETCH_HEAD")
* Any other name of the form "/$name" would be mapped to today's
"refs/$name".
Note that all of the absolute reference listed above, with their leading
"/" removed, have the same interpretation under DWIM as they would as
absolute names under my proposal (provided of course, that there is no
DWIM ambiguity with other reference names).
The only disadvantage that I can see with this scheme is that there
would be no "absolute" notation for a reference that currently has a
full name like "refs/HEAD" (or more generally a reference currently
called "refs/$name" where is_pseudoref_syntax($name) returns true). I
think that is acceptable: (1) such references are probably not in wide
use; (2) we wouldn't (yet) have to prohibit such references; even though
there would be no absolute notation to represent them, their old-style
names would still work.
If we ever decide to go further in banishing "refs/", the next step in
the transition would be to disallow names like "refs/HEAD", treat the
absolute reference names as the "canonical" version, and adding DWIM
rules that treat a prefix "refs/" very much like a leading "/".
Michael
--
Michael Haggerty
mhagger@alum.mit.edu