On 2 October 2011 09:57, Robin Rosenberg <robin.rosenberg@xxxxxxxxx> wrote: > Hilco Wijbenga skrev 2011-08-22 22.10: >> >> [...] I just wish there was at least an option to >> keep the timestamp (and possibly other such things). Even Subversion >> can do that... ;-) After all, not everybody uses C& make. >> > What tools do you use that need the benefits from retaining timestamps? The > only > one I can think of is clearmake, but then that tool goes with another SCM. > Eclipse, > for example, will be just as confused by timestamps that travel backwards in > time, as > make is. Why would timestamps travel back in time? They simply would not change. Anyway, we're not really talking about the same thing. If there's an update (i.e. git pull or something similar) then changing the timestamp to something (anything) newer is the right thing to do. In fact, it would be painful (as you already alluded to) if this were not the case. 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? (Obviously, I moved the discussion off track when I started talking about Subversion, commits, and commit times. That's really just an implementation detail and I wish I had never brought it up.) P.S. I'm quite happy with git-new-workdir so I do believe I have a good workaround. -- 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