Porcelain specific metadata under .git?

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.

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Andreas Ericsson wrote:

Shawn Pearce wrote:

quoted

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

Jakub Narebski wrote:

Andreas Ericsson wrote:

quoted

Shawn Pearce wrote:

quoted

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

Andreas Ericsson [off-list ref] wrote:

Jakub Narebski wrote:

quoted

Andreas Ericsson wrote:

quoted

Shawn Pearce wrote:

quoted

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.