On 1 Apr 2009 at 10:37, Andreas Ericsson wrote: > >> Not only that, but modification times are much more useful with make. > >> Merging or pulling small changes into a tree shouldn't require a full > >> rebuild of the entire tree which in some cases could take hours. > > > > Git is not a build system, and I really dislike "full rebuilds", but for > > stability, before releasing anything, one should test it with a full rebuild. > > I build all the time. Before and after every commit (merges are one type of > commit). I rely on file timestamps to be an accurate indicator of when the > file last changed *on my disk*. > But you are silently assuming that the make files are correct: If a file is not being rebuilt, you might be using an old compile without noticing. There a full recompile will at least 1) either trigger an error (missing object file) or 2) build every file. So I really don't see that relying on file dates is much better than doing a full rebuild. That's specifically true if you pull a new tree: If I understand things right, EVERY file will have a current date, so you'll rebuild everything anyway. So you could also have the "real file dates" and then do "make clean; make all". I see no benefit from either approach. Regards, Ulrich -- 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
