On Mon, Oct 03, 2011 at 12:15:33AM -0700, Hilco Wijbenga wrote:
> 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.
If you really want the human to trigger it, then you can do something
like this:
cat >git-checkout-timestamp <<\EOF
#!/bin/sh
old=`git rev-parse HEAD`
git checkout "$@" || exit 1
time=`git log -1 --format=%at`
git diff-tree --name-only -z "$old" HEAD |
perl -0ne "utime($time, $time, \$_)";
EOF
Drop that somewhere in your $PATH, and use it instead of regular
checkout. It restores the timestamps on any changed files, but not on
those that were not touched. So your:
git checkout branch
git checkout master
example would end up with timestamps set for "master" on the changed
files. Two caveats:
1. This can still break makefiles! For example, like this:
make foo.o ;# now foo.o is recent
vi foo.c ;# but foo.c is _more_ recent
git checkout branch ;# now it's even newer
git checkout-timestamp master ;# now we've restored it to some
;# old timestamp, and make will
;# think it's older than foo.o
2. In general, I'm not sure it makes any sense if there are local
worktree modifications to the files in question. But I didn't think
about it too hard. That ways madness lies.
-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