From: Andreas Ericsson <exon@op5.com>
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: Andreas Ericsson <ae@op5.se>, Russ Dill <russ.dill@gmail.com>,
"H.Merijn Brand" <h.m.brand@xs4all.nl>,
git@vger.kernel.org
Subject: Re: On git 1.6 (novice's opinion)
Date: Wed, 01 Apr 2009 12:17:21 +0200 [thread overview]
Message-ID: <49D33F31.80605@op5.com> (raw)
In-Reply-To: <49D35454.12423.D32681@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> 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.
next prev parent reply other threads:[~2009-04-01 10:20 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-27 7:21 On git 1.6 (novice's opinion) Ulrich Windl
2009-03-27 8:05 ` H.Merijn Brand
2009-03-27 9:50 ` Ulrich Windl
2009-03-27 10:57 ` Etienne Vallette d'Osia
2009-03-27 11:30 ` Etienne Vallette d'Osia
2009-03-27 12:24 ` Dmitry Potapov
2009-03-27 13:39 ` Ulrich Windl
2009-03-27 13:45 ` Matthieu Moy
2009-03-27 13:47 ` Etienne Vallette d'Osia
2009-04-01 6:50 ` Ulrich Windl
2009-04-01 7:41 ` Matthieu Moy
2009-03-28 1:30 ` Junio C Hamano
2009-03-28 1:30 ` Junio C Hamano
2009-03-28 9:53 ` Dmitry Potapov
2009-03-30 6:18 ` Russ Dill
2009-04-01 7:53 ` Ulrich Windl
2009-04-01 8:37 ` Andreas Ericsson
2009-04-01 9:47 ` Ulrich Windl
2009-04-01 10:17 ` Andreas Ericsson [this message]
2009-04-01 20:37 ` Heiko Voigt
2009-03-27 12:24 ` Dmitry Potapov
2009-03-27 13:35 ` Ulrich Windl
2009-03-27 13:44 ` Matthieu Moy
2009-04-01 6:45 ` Ulrich Windl
2009-04-01 7:42 ` Matthieu Moy
2009-03-27 12:49 ` Michael J Gruber
2009-03-27 13:48 ` Ulrich Windl
2009-03-27 14:09 ` Jakub Narebski
2009-04-01 6:59 ` Ulrich Windl
2009-04-01 7:29 ` Andreas Ericsson
2009-04-01 7:54 ` Matthieu Moy
2009-04-01 9:38 ` Ulrich Windl
2009-04-01 10:10 ` Andreas Ericsson
2009-04-02 2:17 ` Jakub Narebski
2009-03-28 10:33 ` demerphq
2009-03-28 1:30 ` Junio C Hamano
2009-04-01 7:35 ` Ulrich Windl
2009-03-29 5:41 ` Bryan Donlan
2009-03-29 9:50 ` Johannes Schindelin
2009-04-01 7:42 ` Ulrich Windl
2009-04-01 7:40 ` Ulrich Windl
2009-03-30 9:06 ` Andreas Ericsson
2009-04-01 8:15 ` Ulrich Windl
2009-04-01 8:41 ` Andreas Ericsson
2009-04-01 9:55 ` Ulrich Windl
2009-04-01 10:21 ` Andreas Ericsson
2009-04-01 11:52 ` Ulrich Windl
2009-04-01 12:40 ` Andreas Ericsson
2009-04-01 2:32 ` Kris Shannon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D33F31.80605@op5.com \
--to=exon@op5.com \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=h.m.brand@xs4all.nl \
--cc=russ.dill@gmail.com \
--cc=ulrich.windl@rz.uni-regensburg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).