Re: On git 1.6 (novice's opinion)

From: Andreas Ericsson <exon@op5.com>
Date: Apr 1, 2009, 10:17 UTC
Message-ID: <49D33F31.80605@op5.com>
In-Reply-To: <49D35454.12423.D32681@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>

Ulrich Windl wrote:

Show 21 quoted lines

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

You'll see the benefit of not rebuilding everything when your projects start spanning more than 30k lines. Buildtesting a subsystem of the linux kernel would be a major pain if object files weren't kept around from previous builds, and integration-testing the hundreds (sometimes) of feature-branches would be completely impossible if timestamps on files weren't updated when files change on disk.

Incidentally, we do full rebuilds too, but no developer sits around watching them. They're handled by our (stupid but efficient) homegrown CI-solution, which emails the results to the devs. This happens every push though, not every commit, but in our rather tight environment at $dayjob we push frequently enough for that not to be a problem.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.