threads / discuss / 4504

Porcelain specific metadata under .git?

Subject: Porcelain specific metadata under .git?

## tl;dr

6 messages between Jun 14, 2006 and Jun 17, 2006.

replies: 5people: 4as markdown or json

Shawn Pearce· Jun 14, 2006, 06:22 UTC · lore

So I'm reaching a point with my Eclipse plugin[*1*] where its actually doing something with a GIT repository and I want to store a ref (to a tree, not a commit) under .git/refs/eclipse-workspaces to help the plugin cache state between workbench restarts. But there doesn't really seem to be any policy to what paths under .git are available for Porcelain and what definately should be off-limits.

I already assume/know that refs/heads and refs/tags are completely off-limits as they are for user refs only.

I also think the core GIT tools already assume that anything directly under .git which is strictly a file and which is named entirely with uppercase letters (aside from "HEAD") is strictly a temporary/short-lived state type item (e.g. COMMIT_MSG) used by a Porcelain.

But is saying ".git/refs/eclipse-workspaces" is probably able to be used for this purpose safe? :-)

[*1*] The Eclipse plugin is getting close to something that is worth releasing as an early alpha for other developers. I think I finally found the last bug in the pack reading code and am now working on the basic operations (add/remove/commit/status). I hope to have all of that working within a few days, at which point I'll publish/announce a public GIT repository with the complete source code and an Eclipse update site for those brave souls who might want to just install it.

-- 
Shawn.
Andreas Ericsson· Jun 14, 2006, 11:11 UTC · re: Shawn Pearce · lore

Re: Porcelain specific metadata under .git?

Shawn Pearce wrote:
Show 13 quoted lines
> 
> I already assume/know that refs/heads and refs/tags are completely
> off-limits as they are for user refs only.
> 
> I also think the core GIT tools already assume that anything
> directly under .git which is strictly a file and which is named
> entirely with uppercase letters (aside from "HEAD") is strictly a
> temporary/short-lived state type item (e.g. COMMIT_MSG) used by a
> Porcelain.
> 
> But is saying ".git/refs/eclipse-workspaces" is probably able to
> be used for this purpose safe?  :-)
> 
.git/eclipse/whatever-you-like

would probably be better. Heads can be stored directly under .git/refs too. Most likely, nothing will ever be stored under ./git/eclipse by either core git or the current (other) porcelains though.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Jakub Narebski· Jun 14, 2006, 11:32 UTC · re: Andreas Ericsson · lore

Re: Porcelain specific metadata under .git?

Andreas Ericsson wrote:
Show 20 quoted lines
> Shawn Pearce wrote:
>> 
>> I already assume/know that refs/heads and refs/tags are completely
>> off-limits as they are for user refs only.
>> 
>> I also think the core GIT tools already assume that anything
>> directly under .git which is strictly a file and which is named
>> entirely with uppercase letters (aside from "HEAD") is strictly a
>> temporary/short-lived state type item (e.g. COMMIT_MSG) used by a
>> Porcelain.
>> 
>> But is saying ".git/refs/eclipse-workspaces" is probably able to
>> be used for this purpose safe?  :-)
>> 
> 
> .git/eclipse/whatever-you-like
> 
> would probably be better. Heads can be stored directly under .git/refs 
> too. Most likely, nothing will ever be stored under ./git/eclipse by 
> either core git or the current (other) porcelains though.

I think if it is a ref, which one wants to be visible to git-fsck (and git-prune), it should be under .git/refs.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Andreas Ericsson· Jun 14, 2006, 13:07 UTC · re: Jakub Narebski · lore

Re: Porcelain specific metadata under .git?

Jakub Narebski wrote:
Show 28 quoted lines
> Andreas Ericsson wrote:
> 
> 
>>Shawn Pearce wrote:
>>
>>>I already assume/know that refs/heads and refs/tags are completely
>>>off-limits as they are for user refs only.
>>>
>>>I also think the core GIT tools already assume that anything
>>>directly under .git which is strictly a file and which is named
>>>entirely with uppercase letters (aside from "HEAD") is strictly a
>>>temporary/short-lived state type item (e.g. COMMIT_MSG) used by a
>>>Porcelain.
>>>
>>>But is saying ".git/refs/eclipse-workspaces" is probably able to
>>>be used for this purpose safe?  :-)
>>>
>>
>>.git/eclipse/whatever-you-like
>>
>>would probably be better. Heads can be stored directly under .git/refs 
>>too. Most likely, nothing will ever be stored under ./git/eclipse by 
>>either core git or the current (other) porcelains though.
> 
> 
> I think if it is a ref, which one wants to be visible to git-fsck (and
> git-prune), it should be under .git/refs.
> 

Yes, but I understood him to mean "it's a tree-sha" instead of a branch/head thing, which would mean it doesn't fit the .git/refs definition of ref.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Junio C Hamano· Jun 14, 2006, 13:30 UTC · re: Andreas Ericsson · lore

Re: Porcelain specific metadata under .git?

Andreas Ericsson <ae@op5.se> writes:
> Yes, but I understood him to mean "it's a tree-sha" instead of a
> branch/head thing, which would mean it doesn't fit the .git/refs
> definition of ref.

I am not sure what you meant by "it's a tree-sha", but if you have an impression that .git/refs define "ref" as committish, you are mistaken. Linus has .git/refs/tags/v2.6.11-tree which tags a tree object. I even have a .git/refs/tags/junio-gpg-pub which tags a blob (blobish ;-> ?).

Shawn Pearce· Jun 17, 2006, 00:43 UTC · re: Andreas Ericsson · lore

Re: Porcelain specific metadata under .git?

Andreas Ericsson <ae@op5.se> wrote:
Show 33 quoted lines
> Jakub Narebski wrote:
> >Andreas Ericsson wrote:
> >
> >
> >>Shawn Pearce wrote:
> >>
> >>>I already assume/know that refs/heads and refs/tags are completely
> >>>off-limits as they are for user refs only.
> >>>
> >>>I also think the core GIT tools already assume that anything
> >>>directly under .git which is strictly a file and which is named
> >>>entirely with uppercase letters (aside from "HEAD") is strictly a
> >>>temporary/short-lived state type item (e.g. COMMIT_MSG) used by a
> >>>Porcelain.
> >>>
> >>>But is saying ".git/refs/eclipse-workspaces" is probably able to
> >>>be used for this purpose safe?  :-)
> >>>
> >>
> >>.git/eclipse/whatever-you-like
> >>
> >>would probably be better. Heads can be stored directly under .git/refs 
> >>too. Most likely, nothing will ever be stored under ./git/eclipse by 
> >>either core git or the current (other) porcelains though.
> >
> >
> >I think if it is a ref, which one wants to be visible to git-fsck (and
> >git-prune), it should be under .git/refs.
> >
> 
> Yes, but I understood him to mean "it's a tree-sha" instead of a 
> branch/head thing, which would mean it doesn't fit the .git/refs 
> definition of ref.

Sorry for the late response to this but I've been busy with real work for the past few days and have not been able to get around to fun work. :-)

Yes, its a tree-sha. There's no point in generating a commit for this tree as it is serving a purpose similar to the index in core GIT. It is a tree which represents the current directory state, or something recently near to it anyway. Not enough information exists to warrant building a commit however, nor is there really any suitable parent for such a commit. Ditto with a tag.

I'm planning on periodically performing a write-tree of the current working directory whenever Eclipse has notified the team provider of tracked resources being modified, with the write-tree occuring no more frequently then a user set threshold, or whenever the project is closed or the workbench is shutdown.

I figure that if the user hasn't re-modified an already "known to be changed" (due to different stat data) file in the last 5 minutes and we haven't written a tree out (for any reason) in the last 15 minutes then maybe we should generate a tree right now as the user is likely to commit one soon. Generating a tree in the background on a low priority thread while the user is busy thinking will make commits "go faster", especially if all I need to do is generate the commit object itself as the tree is already made. :-)

It also just makes things easier, as I need the diff-tree code anyway so making use of that to also track the working directory just seems to make sense.

I want it under .git/refs as I don't really want my in progress tree to go away due to a prune issued by the user. At least not until I have a different tree stored there anyway.

So I'm going to store them under .git/refs/eclipse/some-path.
-- 
Shawn.

← back to recent threads