On Sun, Oct 02, 2011 at 04:40:14PM -0700, Hilco Wijbenga wrote: > That's however not the scenario that I'm talking about. I'm talking about doing > > git checkout branch > git checkout master > > or > > git stash > git stash pop > > In both cases all files (or at least all affected files, in case of > git stash) get the current time as their timestamp instead of the > timestamp they had before. This is forcing (completely unnecessary) > rebuilds. *Nothing* has changed but I have to do a complete rebuild > (well, I suppose I could "touch" all build artifacts and such but I'm > sure you get the idea). > > I understand *why* it's happening (it's simply reusing the existing > Git functionality) but in the scenarios above nothing has really > changed, I should be able to pick up from where I left off, shouldn't > I? No. There are cases where that will fool timestamp-based tools. The problem is that the build products are not tracked by git, and so they are not changed when you switch branches. But the timestamps of build products and branches are compared. So let's imagine you have two branches, with two different versions of foo.c, both of which use "make" to build them into foo.o. Their timestamps are from an hour ago and two hours ago. And that git restores those old timestamps. You do: git checkout master make Now foo.c is one hour old (from master). But foo.o is only a few seconds old (it was just created by make. Now you do: git checkout branch make Now foo.c is two hours old (from branch). But foo.o is still new, so make doesn't rebuild it, which is an error. Or did you really mean your example literally, as in you run two checkouts back to back, without running anything in between, and the second checkout restores the state before the first one. In that case, yes, it would be correct to keep the old timestamps. But this is an optimization that can only apply in a few very specific cases. And moreoever, how can git know when it is OK to apply that optimization? It has no idea what commands you might have run since the last time we were at "master". -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