Andreas Ericsson <ae@xxxxxx> wrote: > 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. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html