Shawn Pearce <spea...@spearce.org> writes:
> On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> Shawn Pearce <spea...@spearce.org> writes:
>>
>>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
