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: Sun, 2 Oct 2011 23:07:23 -0400 [thread overview]
Message-ID: <20111003030723.GA24523@sigill.intra.peff.net> (raw)
In-Reply-To: <CAE1pOi3bm72Rk+UYygS_bC9eh0VTPr-VQSdtBGqjgDpEzkutZw@mail.gmail.com>
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
next prev parent reply other threads:[~2011-10-03 3:07 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 [this message]
2011-10-03 7:15 ` Hilco Wijbenga
2011-10-03 7:30 ` Jeff King
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=20111003030723.GA24523@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).