Douglas Campos <douglas@xxxxxxxxxxx> wrote: > I'm interested in helping with the implementation, can someone gimme > little directions? > > I was thinking on implement "git checkout <file>" functionality. > > Any tips? > > PS: I'm reading the testcases & code to find directions, but got > struck at some deprecated types (GitIndex -> DirCache). Sorry for the late reply, things tend to get lost in my inbox. GitIndex vs. DirCache... that's an ugly issue at the momement in the code base. I really want to move to DirCache because it tends to be quicker at reading and writing the index out, plus it honors the 'TREE' extension, at least some of the time. But its API is said to be harder to work with, and I can't disagree with that, using the DirCacheBuilder vs. DirCacheEditor to make updates is horribly ugly. FWIW, DirCacheBuilder is really meant to be used inside of a TreeWalk, alongside other iterators, like a FileTreeIterator. In theory, you should be able to create a 3 way TreeWalk between: 1) DirCacheBuilderIterator 2) FileTreeIterator 3) CanonicalTreeParser where 1 represents the current state of the .git/index file, 2 represents the current state of the working directory, and 3 represents the tree you are performing the checkout from. IIRC you could attach a TreeFilter.ANY_DIFF to this TreeWalk and only have it stop where there are differences between the 3 trees. Though with a FileTreeIterator ANY_DIFF is probably a bad idea, as the SHA-1 isn't readily available in a FileTreeIterator and that is one of the things ANY_DIFF relies upon. Instead you'd need to write your own TreeFilter to check stat data between 1-2, and SHA-1 data between 2-3. At a difference point, you then need to apply the basic 3-way merge logic to determine if you should checkout the file in 3 to 1 and 2, or if you should abort because the file in 2 (the working tree) differs and needs to be merged. A really good reason for using the TreeWalk is it has a subclass called NameConflictTreeWalk that knows how to heal around directory/file conflicts (aka D/F conflicts) and reports both D/F paths under a single entry, so that the merge alogrithm can attempt to deal with D->F or F->D type changes. But a good chunk of this is pie-in-the-sky. I've built these APIs with this in mind... but haven't gotten as far as actually putting the implementation into practice. -- Shawn. -- 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