On 3 October 2011 07:59, Robin Rosenberg <robin.rosenberg@xxxxxxxxx> wrote: > Hilco Wijbenga skrev 2011-10-03 09.15: >> >> On 2 October 2011 20:07, Jeff King<peff@xxxxxxxx> wrote: >> <snip/> >>> >>> 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". >> >> Yes, I meant it literally. And, no, Git could not possibly know so it >> would have to be optional behaviour. But it's probably a lot of work >> for (for most people) little gain. >> -- >> 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 >> > I wouldn't use stash for that. Just regular commit/amend and your > timestamps should be fine. Alternative submit a patch for either > the save or create subcommands of stash. That would not be very > hard (technically) and no one needs to mess with the timestamps; > they will just survive. By "that" you mean jump to another branch? I don't see how doing an explicit commit changes anything. Stashing is essentially committing (i.e. a "dummy" commit is created to store the stash, IIUC), isn't it? As I mentioned before, I'm quite happy with git-new-workdir. It allows me to work exactly the way I want. I may have some philosophical reservations about Git's timestamp handling but practically speaking I'm a happy little camper. :-) -- 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