Michael Haggerty writes:
> 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 exampl
On 12/22/2015 08:34 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote:
>>> Shawn Pearce writes:
>>>
> But really, aside from slightly helping
> disambiguate references from paths in the command line, what is it good
> for?
>
Martin Fick writes:
> ... 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
Yeah, that is one way to allow a tool to be absolutely certain there
is no funny DWIMmery goin
On Tuesday, December 22, 2015 06:17:28 PM you wrote:
> On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty
wrote:
>
> At a deeper level, the "refs/" part of reference names is
> actually pretty useless in general. I suppose it
> originated in the practice of storing loose references
> under "refs/"
Shawn Pearce writes:
> On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote:
>> Shawn Pearce 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 enc
On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote:
> Shawn Pearce 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
Shawn Pearce 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 o
On Tue, Dec 22, 2015 at 9:17 AM, Michael Haggerty wrote:
>
> etc. But we store branches into the main "refs/remotes/origin/"
> namespace, leaving no reserved space for the remote "HEAD" (not to
> mention other namespaces that might appear on the remote, such as
> "refs/changes/*", "refs/pull/*", a
On 12/22/2015 05:11 PM, Shawn Pearce wrote:
> On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty
> wrote:
>> On 12/17/2015 10:02 PM, Shawn Pearce wrote:
>>> I started playing around with the idea of storing references directly
>>> in Git. Exploiting the GITLINK tree entry, we can associate a name
On Tue, Dec 22, 2015 at 8:11 AM, Shawn Pearce wrote:
> Yup, and Gerrit Code Review servers often have 100k+ refs per
> repository. We can't rewrite the entire store every time either. So
> its not a flat list. Its a directory structure using the / separators
> in the ref namespace.
I wonder if th
On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty wrote:
> On 12/17/2015 10:02 PM, Shawn Pearce wrote:
>> I started playing around with the idea of storing references directly
>> in Git. Exploiting the GITLINK tree entry, we can associate a name to
>> any SHA-1.
>>
>> By storing all references in
On 12/17/2015 10:02 PM, Shawn Pearce wrote:
> I started playing around with the idea of storing references directly
> in Git. Exploiting the GITLINK tree entry, we can associate a name to
> any SHA-1.
>
> By storing all references in a single tree, atomic transactions are
> possible. Its a simple
On Thu, Dec 17, 2015 at 02:28:01PM -0800, Shawn Pearce wrote:
> On Thu, Dec 17, 2015 at 2:10 PM, Jeff King wrote:
> > On Thu, Dec 17, 2015 at 01:02:50PM -0800, Shawn Pearce wrote:
> >
> >> I started playing around with the idea of storing references directly
> >> in Git. Exploiting the GITLINK tre
On Thu, Dec 17, 2015 at 2:10 PM, Jeff King wrote:
> On Thu, Dec 17, 2015 at 01:02:50PM -0800, Shawn Pearce wrote:
>
>> I started playing around with the idea of storing references directly
>> in Git. Exploiting the GITLINK tree entry, we can associate a name to
>> any SHA-1.
>
> Gitlink entries do
On Thu, Dec 17, 2015 at 1:57 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> For example, recent git.git has a structure like this:
>>
>> $ git ls-tree -r refs/txn/committed
>> 12 blob 22e42fc826b437033ca444e09368f53a0b169322 ..HEAD
>> 16 commit 1ff88560c8d22bcdb528a6629239d63
On Thu, Dec 17, 2015 at 01:02:50PM -0800, Shawn Pearce wrote:
> I started playing around with the idea of storing references directly
> in Git. Exploiting the GITLINK tree entry, we can associate a name to
> any SHA-1.
Gitlink entries don't imply reachability, though. I guess that doesn't
matter
Shawn Pearce writes:
> For example, recent git.git has a structure like this:
>
> $ git ls-tree -r refs/txn/committed
> 12 blob 22e42fc826b437033ca444e09368f53a0b169322 ..HEAD
> 16 commit 1ff88560c8d22bcdb528a6629239d638f927cb96 heads/maint
> 16 commit f3adf457e046f92f03935376
I started playing around with the idea of storing references directly
in Git. Exploiting the GITLINK tree entry, we can associate a name to
any SHA-1.
By storing all references in a single tree, atomic transactions are
possible. Its a simple compare-and-swap of a single 40 byte SHA-1.
This of cour
18 matches
Mail list logo
