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

RE: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

From
CCCraig L. Ching <cching@mqsoftware.com>
Date
Jul 31, 2008, 20:37 UTC
Message-ID
<63BEA5E623E09F4D92233FB12A9F79430238A5FF@emailmn.mqsoftware.com>
In-Reply-To
<alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org>
Show 6 quoted lines
> From: Linus Torvalds [mailto:torvalds@linux-foundation.org] 
> Sent: Thursday, July 31, 2008 3:09 PM
> 
> Sure, if you want to keep the build tree around, you would 
> probably not use branches. 
> 

I think we'd still use branches, but we just need to isolate their workdirs from each other.

Show 21 quoted lines
> But yes, then you'd likely do "git clone -s" with some single 
> "common point" or use "git worktree". And even if you don't 
> use "-s", you should _still_ effectively share at least all 
> the old history (which tends to be the bulk) thanks to even a 
> default "git clone" will just hardlink the pack-files.
> 
> So literally, if you do
> 
> 	git clone <cntral-repo-over-network> <local>
> 
> and then do
> 
> 	git clone <local> <otherlocal>
> 	git clone <local> <thirdlocal>
> 
> then all of those will all share the initial pack-file 
> on-disk. Try it.
> 
> (You may then want to edit the "origin" branch info in the 
> .git/config to point to the network one etc, of course).
> 

Yes, thank you for the explanation. Having used git a fair amount now, that makes perfect sense to me, in fact, it sounds a lot like git-new-workdir, but I think I'll change our use of git-new-workdir to something more "core" git. It seems to me that maybe this is something that could be documented more prominently? Or maybe it is and I've just missed it. This would have saved me a lot of time originally to be sure.

Show 6 quoted lines
> Oh, and to make sure I'm not lying I actually did test this, 
> but I also noticed that "git clone" no longer marks the 
> initial pack-file with "keep", so it looks like "git gc" will 
> then break the link. That's sad. I wonder when that changed, 
> or maybe I'm just confused and it never did.
> 

What's the consequence of that then? Because of that, would you say "don't gc your master local repo until all derived repos are merged?" If that link is broken is it just a loss of space? Or is it more?

> 		Linus
> 
Thanks again!

Cheers, Craig

Previous: Shawn O. PearceNext: Björn Steinbrink
Message 20 of 33 in “Git vs Monotone”
  1. Sverre RabbelierJul 31, 2008
  2. Stephen R. van den BergJul 31, 2008
  3. Petr BaudisJul 31, 2008
  4. Jeff KingJul 31, 2008
  5. Craig L. ChingJul 31, 2008
  6. Sverre RabbelierJul 31, 2008
  7. Jeff KingJul 31, 2008
  8. Linus TorvaldsJul 31, 2008
  9. Craig L. ChingJul 31, 2008
  10. Linus TorvaldsJul 31, 2008
  11. Junio C HamanoJul 31, 2008
  12. Linus TorvaldsJul 31, 2008
  13. Felipe ContrerasAug 23, 2008
  14. Blum, RobertJul 31, 2008
  15. Robin RosenbergAug 10, 2008
  16. David KastrupAug 1, 2008
  17. Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)Craig L. Ching, Jul 31, 2008
  18. Linus TorvaldsJul 31, 2008
  19. Shawn O. PearceJul 31, 2008
  20. Craig L. ChingJul 31, 2008
  21. Björn SteinbrinkJul 31, 2008
  22. Avery PennarunJul 31, 2008
  23. Linus TorvaldsJul 31, 2008
  24. Martin LanghoffJul 31, 2008
  25. Linus TorvaldsJul 31, 2008
  26. Dmitry TorokhovAug 1, 2008
  27. Linus TorvaldsAug 1, 2008
  28. Linus TorvaldsAug 1, 2008
  29. Sean EstabrooksJul 31, 2008
  30. Theodore TsoJul 31, 2008
  31. Theodore TsoJul 31, 2008
  32. Sverre RabbelierAug 1, 2008
  33. Daniel BarkalowAug 1, 2008

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.