Thanks Jeff. I recognize your picture from here... http://git.661346.n2.nabble.com/push-race-td7569254.html ... which helped me figure out how two processes trying to update a ref at the same time works out. I will try using a separate GIT_INDEX_FILE for each working tree. I'm not certain that what I'm trying to do is even a good idea. We have a system which is the official storage of things we'll just call "items". These items have one or more "revisions". These revisions can have all sorts of relationships to other revisions. Once a revision is released it is locked down and cannot be changed including the revisions. Rather than working directly with this official storage system, we want our application to work against a concept of a "local workspace". This is where I want to use Git. We can map a released revision to a tree structure by getting all the files, serializing all the attributes, relation data, etc. That tree structure is what I would store in Git. My options seem to be 1) use a single Git repo to store all items in a disconnected manner (each item has a branch disconnected (orphaned?) from the other branches) 2) each item gets its own Git repo 3) use a single Git repo to store all items but have them all together in a workspace I'm pursuing option (1) right now and trying to see how much work it would take. With option (2) I think that would limit my ability to send a bunch of items from one repo to another. Option (3) doesn't really map to the system we're trying to mimic because releases are done at the "item revision" level, not at a higher workspace level. On Wed, Feb 18, 2015 at 1:32 PM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Feb 18, 2015 at 01:27:50PM -0500, Eric Frederich wrote: > >> My immediate concern is not to fix the documentation but to get some >> sort of status or diff. >> I want to avoid using an index because I want to allow multiple >> processes to do different diffs at the same time. > > If you only have one working tree, can't all of the processes use the > same index (that matches the working tree) and do different diffs > against it? > > If you have multiple working trees, can you use one index per working > tree, and specify it using GIT_INDEX_FILE? > > If you can persist the index file for each working tree, this will be > much faster in the long run, too (you can just refresh the index before > each diff, which means that git does not have to actually open the files > in most cases; we can compare their stat information to what is in the > index, and then the index sha1 with what is in the tree). > > -Peff -- To unsubscribe from this list: 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