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 -- 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