Dominik Vogt <[email protected]> writes:
> Me and some colleagues work on gcc in lots of different branches.
> For each branch there is a separate build directory for each
> branch, e.g. build-a, build-b and build-c. Let's assume that all
> branches are identical at the moment. If a file in branch a is
> changed that triggers a complete rebuild of gcc (e.g.
> <target>.opt), rebuilding in build-a takes about an hour. 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 am not quite sure I follow your set-up. Do you have three working
trees connected to a repository (via contrib/workdir/git-new-workdir
perhaps), each having a checkout of its own branch? And in one
working directory that has build-a checked out, a new commit touches
one file, <target>.opt, to make a new commit:
Before:
---o---o---X
^ refs/heads/build-a
refs/heads/build-b
refs/heads/build-c
After:
v refs/heads/build-a
---o---o---X---Y
^ refs/heads/build-b
refs/heads/build-c
Because you said that branch b and c hasn't changed at all, I do not
see how your build-b and/or build-c directories become dirty.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
