Re: Porcelain specific metadata under .git?

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.