From: Dmitry Potapov <dpotapov@gmail.com>
To: The Git Mailing List <git@vger.kernel.org>
Subject: Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
Date: Wed, 2 Dec 2009 00:18:30 +0300 [thread overview]
Message-ID: <20091201211830.GE11235@dpotapov.dyndns.org> (raw)
In-Reply-To: <m1NFXvL-000kn2C@most.weird.com>
On Tue, Dec 01, 2009 at 01:58:05PM -0500, Greg A. Woods wrote:
>
> > > I just disagreed that "git archive" was a reasonable alternative to
> > > leaving the working directory alone during the entire time of the build.
> >
> > Using "git archive" allows you avoid running long time procedure such as
> > full clean build and testing in the working tree. Also, it is guaranteed
> > that you test exactly what you put in Git and some other garbage in your
> > working tree does not affect the result.
>
> Sure, but let's be very clear here: "git archive" is likely even more
> impossible for some large projects to use than "git clone" would be to
> use to create build directories.
AFAIK, "git archive" is cheaper than git clone. I do not say it is fast
for huge project, but if you want to run a process such as clean build
and test that takes a long time anyway, it does not add much to the
total time.
>
> Disk bandwidth is almost always more expensive than disk space.
Disk bandwidth is certainly more expensive than disk space, and the
whole point was to avoid a lot of disk bandwidth by using hot cache.
If you have two working tree then it is likely that only one will be
in the hot cache, that is why you can switch faster (and to recompile
a few files) than going to another working tree. It has never been
about disk space, it is about disk cache and keeping it hot.
>
> Multiple working directories are really the only sane solution
> sometimes.
Sure, sometimes... I do not know details to say what will be better in
your case, but I just wanted to say that you should weight that against
switching, because switching in Git is very fast. Much faster than with
any other VCS...
Another thing to consider is that if you put a really huge project in one
Git repo than Git may not be as fast as you may want, because Git tracks
the whole project as the whole. So, you may want to split your project in
a few relatively independent modules (See git submodule).
Dmitry
next prev parent reply other threads:[~2009-12-01 21:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-29 3:21 "git merge" merges too much! Greg A. Woods
2009-11-29 5:14 ` Jeff King
2009-11-30 18:12 ` Greg A. Woods
2009-11-30 19:22 ` Dmitry Potapov
2009-12-01 18:52 ` Greg A. Woods
2009-12-01 20:50 ` Dmitry Potapov
2009-12-01 21:58 ` Greg A. Woods
2009-12-02 0:22 ` Dmitry Potapov
2009-12-02 10:20 ` Nanako Shiraishi
2009-12-02 20:09 ` Jeff King
2009-12-03 1:21 ` Git documentation consistency (was: "git merge" merges too much!) Greg A. Woods
2009-12-03 1:34 ` Git documentation consistency Junio C Hamano
2009-12-03 7:22 ` Greg A. Woods
2009-12-03 7:45 ` Jeff King
2009-12-03 15:24 ` Uri Okrent
2009-12-03 16:22 ` Marko Kreen
2009-12-09 19:56 ` Greg A. Woods
2009-12-03 2:07 ` Git documentation consistency (was: "git merge" merges too much!) Jeff King
2009-11-29 5:15 ` "git merge" merges too much! Junio C Hamano
2009-11-30 18:40 ` Greg A. Woods
2009-11-30 20:50 ` Junio C Hamano
2009-11-30 21:17 ` Dmitry Potapov
2009-12-01 0:24 ` Greg A. Woods
2009-12-01 5:47 ` Dmitry Potapov
2009-12-01 17:59 ` multiple working directories for long-running builds (was: "git merge" merges too much!) Greg A. Woods
2009-12-01 18:51 ` Dmitry Potapov
2009-12-01 18:58 ` Greg A. Woods
2009-12-01 21:18 ` Dmitry Potapov [this message]
2009-12-01 22:25 ` Jeff Epler
2009-12-01 22:44 ` Greg A. Woods
2009-12-02 0:10 ` Dmitry Potapov
2009-12-03 5:11 ` Greg A. Woods
2009-12-02 2:09 ` multiple working directories for long-running builds Junio C Hamano
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=20091201211830.GE11235@dpotapov.dyndns.org \
--to=dpotapov@gmail.com \
--cc=git@vger.kernel.org \
/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).