Bug 45551 – git-svn, branches and rebuilding

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Tools / Tests

[Robert Hogan]

In a git-svn clone with 'git config core.webKitBranchBuild true' if you do:

git checkout -b somebranch master
./build-webkit etc.
git checkout -b newbranch master
git checkout somebranch
./build-webkit etc.

the second build command triggers a full rebuild when building QtWebKit - not sure about other ports.

This is very inconvenient. I think it's caused by the timestamps on the generated files.

Is there anyway of fixing it?

[Eric Seidel (no email)]

I believe that's the intention of webkitBranchBuild.  I don't use it for just that reason. :)  I don't want a separate build directory per branch.

[Eric Seidel (no email)]

Actually, I think the problem here is that I suspect git is changing the timestamps when it checks out the files.  the mod times.  Your build system is going to notice that the mod times changed on the files in question and force a rebuild (since they'll be newer mod times than the object files).

I don't remember who added the webkitBranchBuild thing.  We should remove it if no one finds it useful.  (Again, I'm not the right person to ask about it, since I've not found it useful.)

[Antonio Gomes]

(In reply to comment #2)
> Actually, I think the problem here is that I suspect git is changing the timestamps when it checks out the files.  the mod times.  Your build system is going to notice that the mod times changed on the files in question and force a rebuild (since they'll be newer mod times than the object files).
> 
> I don't remember who added the webkitBranchBuild thing.  We should remove it if no one finds it useful.  (Again, I'm not the right person to ask about it, since I've not found it useful.)

This is not a bug. It is what comment above say.

Git plugins have been written to improve this. See http://marc.info/?l=git&m=128616773419532&w=2

One could just improve the UsingGitWithWebKit wiki page and close this bug as invalid I think.

[Evan Martin]

Yes, Antonio is right.


git intentionally touches the timestamps of all modified files.

The problem it's addressing is:

start on branch 1
checkout a.cc
compile to a.o

switch to branch 2:
checks a new a.cc
compile produces a new a.o

switch back to branch 1:
checks out the old a.cc again
if we restored the old timestamp of a.cc, build tools would now think a.o is the correct output of compiling a.cc


webKitBranchBuild is a way to work around this problem, by making it so we'd have different paths for a.o in different branches.  In that circumstance, it would be fine for git to restore the old mtime.  But that is a git feature request, not a webkit one.