On Mon, 5 Mar 2007, Bill Lear wrote: > > Maybe, maybe not. Each argument I've seen doesn't convince me. Sure, > it may be MESSY. It may be UGLY, and therefore undesirable, but I > don't think any of the arguments have conclusively shown that it > is WRONG or INFEASIBLE in any way. I'm sorry. If you don't see how it's WRONG to seta datestamp back to something that will make a simple "make" *miscompile* your source tree, I don't know what defintiion of "wrong" you are talking about. It's WRONG. It's STUPID. And it's totally INFEASIBLE to implement. > Why should I care whether git knows this? I never said it should. As > I said, if I have make products in separate, per-branch directories (a > minor extension to my current make system), I don't see how this would > be confusing in the least. Git should only care if the content of the > file in the index changes. It shouldn't care in the least about my > make products. But Bill, the content in the index *does* change. It's that simple. It changes every time you check out another branch. And if it doesn't change, git already avoids changing mtime (because git already avoids changing the file). > Here's the flow. Perhaps I'm fundamentally confused, and I'll be > the first to admit that is true in plenty of ways: > > I edit sourcefile.c, compile it, then commit it with > N=timestamp(sourcefile.c) on master. N is < > timestamp(.master/sourcefile.o). I then switch to branchX. N is > stored by git for master:sourcefile.c. No stored timestamp are on > this branch, so the file gets the timestamp it gets on checkout > M=timestamp(sourcefile.c). I compile the file again, all is well. I > move back to master branch. Git stores M as branchX:sourcefile.c Git > checks out the file, and stamps it with N. I do a make. No > recompilation happens. WHICH IS WRONG! You need to recompile, since the compile you did on the other branch DOES NOT MATCH in "sourcefile.c" any more. And if sourcefile.c _does_ match in the two branches, then git *already* won't have changed it at all, so git already does the obvious optimization. The thing is, "ccache" actually does this right. You could arguably integrate ccache with more git integration, and let ccache just use the SHA1's that git already caches and knows about. But the real issue is that what _you_ suggest is crazy. It doesn't work. Linus - 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