Dmitry Potapov <dpotapov <at> gmail.com> writes: > Actually, in most use cases, there is no reason to have more than one > working tree. Git is designed to work well with plenty branches and one > working tree. So, switching between two branches and recompiling a few > changed files is much faster then going to another directory and try to > work there, because when you go to another directory, you may hit cold > cache and disk is *slow*... Another thing is that you can do a lot of > things without checking out some branch. You can grep any revision in > your repository, you can insect any file from it, etc and you do not > have to checkout this revision in your working tree. Shouldn't I even worry about my not yet commited changes before switching the branch? I would say that this approach does not work if the build and test could take significant time. While in CR fix I don't want to wait for a build to complete before I countinue with another bug/fix. That is why I'm curious about few working trees... -- 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