Re: mtimes of working files

On Sat, 14 Jul 2007, David Woodhouse wrote:

This seems to be very personal.

I tend to use just temporary branches, but I love just going on another branch, fixing something up, and working on that without having to set up a whole new tree. It's *much* faster to just switch branches than to do even a local clone, because I usually would work on something that is pretty close to the HEAD anyway, so the cost of rewriting a few hundred files is much less than checking out the 22,000 files all over again.

But I literally tend to just use branches for something small. I don't personally tend to have any long-term live branches (apart from the remove ones, obviously). I create a branch, do something in it, merge it, and go back to master.

The last example of this for me was just re-doing a pull by Ingo, because he had created some really strange commit in his tree, so I fetched his stuff, re-created his branch locally without the thing, and then merged it. And then I just deleted the branch.

I don't even use ccache, and I don't care. Probably because most of the time the rebuild time really isn't that long for me, and for the kernel, the much more painful part is actually the rebooting part.

But the place where branches *really* rock is when you don't even switch to them, but use the data from them locally (cherry-picking from them, or doing something like "git show origin/pu:builtin-blame.c" etc).

And for that to work, you have to get used to having multiple branches in the tree, even if you don't check them out - and once you do that, switching between them isn't really that confusing any more, because it's already part of your "mind map" of how the repo works.

			Linus