From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mon, 09 Dec 2013 20:48:16 GMT
Subject: Re: Setting file timestamps to commit time (git-checkout)
Message-ID: <20131209204815.GV29959@google.com>
In-Reply-To: <20131209112528.GA5309@linux.vnet.ibm.com>

Hi,

Dominik Vogt wrote:

>                                                            Now,
> when I switch to one of the other branches, said file is not
> identical anymore and stamped with the _current_ time during
> checkout.  Although branch b and c have not changed at all, they
> will now be rebuilt completely because the timestamp on that files
> has changed.  I.e. a chance on one branch forces a rebuild on n
> other branches, which can take many hours.
>
> I think this situation could be improved with an option to
> git-checkout with the following logic:
>
> $ git checkout <new branch>
>   FOR EACH <file> in working directory of <new branch>
>     IF <file> is identical to the version in the <old branch>
>       THEN leave the file untouched
>     ELSE IF <commit timestamp> of the HEAD of the <new branch>
>             is in the future
>       THEN checkout the new version of <file> and stamp it with
>            the current time
>     ELSE (commit timestamp is current or in the past)
>       THEN checkout the new version of <file> and stamp it with
>            the commit timestamp of the current HEAD of <new branch>

Wouldn't that break "make"?  When you switch to an old branch, changed
files would then a timestamp *before* the corresponding build targets,
causing the stale (wrong function signatures, etc) build results from
the newer branch to be reused and breaking the build.

I suspect the simplest way to accomplish what you're looking for would
be to keep separate worktrees for each branch you regularly build.
It's possible to do that using entirely independent clones, clones
sharing some objects (using "git clone --shared" from some master
copy), or even multiple worktrees for the same clone (using the
git-new-workdir script from contrib/workdir/).

See [1] and [2] for more hints.

[...]
> (Please do not cc me on replies, I'm subscribed to the list.)

The convention on this list is to always reply-to-all, but I'm happy
to make an exception. :)

Hope that helps,
Jonathan

[1] https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F
[2] https://git.wiki.kernel.org/index.php/ExampleScripts#Setting_the_timestamps_of_the_files_to_the_commit_timestamp_of_the_commit_which_last_touched_them