All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Hilco Wijbenga <hilco.wijbenga@gmail.com>
Cc: Robin Rosenberg <robin.rosenberg@gmail.com>,
	Kyle Moffett <kyle@moffetthome.net>,
	Michael Witten <mfwitten@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Evan Shelhamer <shelhamer@imaginarynumber.net>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Branches & directories
Date: Mon, 3 Oct 2011 03:30:59 -0400	[thread overview]
Message-ID: <20111003073059.GA9455@sigill.intra.peff.net> (raw)
In-Reply-To: <CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com>

On Mon, Oct 03, 2011 at 12:15:33AM -0700, Hilco Wijbenga wrote:

> On 2 October 2011 20:07, Jeff King <peff@peff.net> 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

  reply	other threads:[~2011-10-03  7:31 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-17 18:35 Branches & directories Hilco Wijbenga
2011-08-17 18:47 ` Evan Shelhamer
2011-08-17 19:14   ` Junio C Hamano
2011-08-17 21:23     ` Hilco Wijbenga
2011-08-18  4:45       ` Jonathan Nieder
2011-08-21 19:48         ` Hilco Wijbenga
2011-08-18  5:52       ` Michael Witten
2011-08-18 10:56         ` Michael J Gruber
2011-08-18 17:49           ` Michael Witten
2011-08-19  0:13         ` Jonathan Nieder
2011-08-21 20:25         ` Hilco Wijbenga
2011-08-21 20:53           ` Michael Witten
2011-08-21 21:37             ` Hilco Wijbenga
2011-08-21 23:06               ` Michael Witten
2011-08-21 23:35                 ` Hilco Wijbenga
2011-08-22  0:07                   ` Michael Witten
2011-08-22  0:47                     ` Hilco Wijbenga
2011-08-22  1:53                       ` Hilco Wijbenga
2011-08-22  2:05                       ` Michael Witten
2011-08-22  2:13                         ` Hilco Wijbenga
2011-08-22  3:01                           ` Kyle Moffett
2011-08-22  5:36                             ` Hilco Wijbenga
2011-08-22 12:46                               ` Kyle Moffett
2011-08-22 18:49                                 ` Hilco Wijbenga
2011-08-22 19:31                                   ` Kyle Moffett
2011-08-22 20:10                                     ` Hilco Wijbenga
2011-08-22 21:01                                       ` Restoring timestamps (Re: Branches & directories) Jonathan Nieder
2011-08-22 22:33                                         ` Hilco Wijbenga
2011-08-22 23:21                                           ` Jonathan Nieder
2011-08-23  3:06                                             ` Hilco Wijbenga
2011-08-23  3:20                                               ` Hilco Wijbenga
2011-10-02 15:06                                               ` Enrico Weigelt
2011-10-02 22:29                                                 ` Hilco Wijbenga
     [not found]                                               ` <CA+sFfMf=gi5CWyfZEt-Nmdr4J9g__maQTqy1WePr1x8D-AVr4A@mail.gmail.com>
2011-10-02 22:25                                                 ` Hilco Wijbenga
2011-08-23 14:46                                       ` Branches & directories Michael Witten
2011-10-02 16:57                                       ` Robin Rosenberg
2011-10-02 17:31                                         ` Ronan Keryell
2011-10-02 19:09                                           ` Matthieu Moy
2011-10-02 23:45                                             ` Hilco Wijbenga
2011-10-02 23:40                                         ` Hilco Wijbenga
2011-10-03  3:07                                           ` Jeff King
2011-10-03  7:15                                             ` Hilco Wijbenga
2011-10-03  7:30                                               ` Jeff King [this message]
2011-10-03  7:32                                               ` Matthieu Moy
2011-10-03  7:34                                                 ` Jeff King
2011-10-03  7:41                                                   ` Matthieu Moy
2011-10-03  7:44                                                     ` Jeff King
2011-10-03  7:48                                                       ` Junio C Hamano
2011-10-03  7:51                                                         ` Jeff King
2011-10-03 17:31                                                 ` Hilco Wijbenga
2011-10-03 14:59                                               ` Robin Rosenberg
2011-10-03 17:20                                                 ` Hilco Wijbenga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111003073059.GA9455@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hilco.wijbenga@gmail.com \
    --cc=kyle@moffetthome.net \
    --cc=mfwitten@gmail.com \
    --cc=robin.rosenberg@gmail.com \
    --cc=shelhamer@imaginarynumber.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.