David Turner <dturner@xxxxxxxxxxxxxxxx> writes: >> I am not convinced that doing an equivalent of write-tree when you >> switch branches is the right approach in the first place. You will >> eventually write it out as a tree, and having a relatively undamaged >> cache-tree will help you when you do so, but spending the cycles >> necessary to compute a fully populated cache-tree, only to let it >> degrade over time until you are ready to write it out as a tree, >> somehow sounds like asking for a duplicated work upfront. > > As I understand it, the cache-tree extension was originally designed to > speed up writing the tree later. However, as Karsten Blees's work (and > my own tests) have shown, it also speeds up git status. I use git > status a lot while working, and I've talked to a few others who do the > same. So I think it's worth spending extra time when switching branches > to have a good working experience within that branch. You are reading the history of the subsystem correctly. Since b65982b6 (Optimize "diff-index --cached" using cache-tree, 2009-05-20), having an undamaged cache-tree does help with "git status" as well. > In the new version of the patchset (which I'll post shortly), I've added > an option WRITE_TREE_REPAIR, which does all of the work to compute a new > tree object, but only adds it to the cache-tree if it already exists > on-disk. This is a little wasteful for the reason that you note. So if > you would like, I could add a config option to skip it. But I think it > is a good default. OK, sounds good. -- 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