Shawn Pearce [off-list ref] writes:
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?
On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano [off-list ref] wrote:
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/
All of the code that is handed a ref name knows its a ref name and not
a sha-1 object name in the objects directory.
The catch is a few things accept HEAD, MERGE_HEAD, FETCH_HEAD, etc.
Those have to be handled even though they aren't in the refs/
directory.