git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: multiple working directories for long-running builds (was: "git merge" merges too much!)

From
Dmitry Potapov <dpotapov@gmail.com>
Date
Dec 1, 2009, 21:18 UTC
Message-ID
<20091201211830.GE11235@dpotapov.dyndns.org>
In-Reply-To
<m1NFXvL-000kn2C@most.weird.com>
On Tue, Dec 01, 2009 at 01:58:05PM -0500, Greg A. Woods wrote:
Show 12 quoted lines
> 
> > > 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
Previous: Greg A. WoodsNext: Jeff Epler
Message 28 of 33 in “"git merge" merges too much!”
  1. Greg A. WoodsNov 29, 2009
  2. Jeff KingNov 29, 2009
  3. Greg A. WoodsNov 30, 2009
  4. Dmitry PotapovNov 30, 2009
  5. Greg A. WoodsDec 1, 2009
  6. Dmitry PotapovDec 1, 2009
  7. Greg A. WoodsDec 1, 2009
  8. Dmitry PotapovDec 2, 2009
  9. Nanako ShiraishiDec 2, 2009
  10. Jeff KingDec 2, 2009
  11. Greg A. WoodsDec 3, 2009
  12. Junio C HamanoDec 3, 2009
  13. Greg A. WoodsDec 3, 2009
  14. Jeff KingDec 3, 2009
  15. Uri OkrentDec 3, 2009
  16. Marko KreenDec 3, 2009
  17. Greg A. WoodsDec 9, 2009
  18. Jeff KingDec 3, 2009
  19. Junio C HamanoNov 29, 2009
  20. Greg A. WoodsNov 30, 2009
  21. Junio C HamanoNov 30, 2009
  22. Dmitry PotapovNov 30, 2009
  23. Greg A. WoodsDec 1, 2009
  24. Dmitry PotapovDec 1, 2009
  25. Greg A. WoodsDec 1, 2009
  26. Dmitry PotapovDec 1, 2009
  27. Greg A. WoodsDec 1, 2009
  28. Dmitry PotapovDec 1, 2009
  29. Jeff EplerDec 1, 2009
  30. Greg A. WoodsDec 1, 2009
  31. Dmitry PotapovDec 2, 2009
  32. Greg A. WoodsDec 3, 2009
  33. Junio C HamanoDec 2, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.