Re: Setting file timestamps to commit time (git-checkout)

[Dominik Vogt <vogt@linux.vnet.ibm.com>]

On Mon, Dec 09, 2013 at 12:48:16PM -0800, Jonathan Nieder wrote:
> Dominik Vogt wrote:
> > 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.

Yes, if you share a common build directory, this logic would
utterly break the build system.  The point with gcc is, that you
do not build it in the source tree but in a separate build
directory, and it's easy to have separate build directories for
your branches.

> 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/).

I've tried the first two ways for separate workdirs in the past
but did not like them.  How does git-new-workdir cope with
rebasing (e.g. you have the same branch checked out in two working
trees and "rebase -i" it in one of them)?  Is it really a working
option?

> > (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. :)

It's just a hint; anyway, I guess I should remove the Reply-To
header if I don't want direct replies.  ;-)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany