On Thu, 31 Jul 2008, Craig L. Ching wrote: > > We find ourselves constantly having to shift gears and work on other > things in the middle of whatever it is we're currently working on. For > instance, in the scenario above, A might be branch that contains a > feature going into our next release. B might be a bugfix and takes > priority over A, so you have to leave A as-is and start work on B. When > I come back to work on A, I have to rebuild A to continue working, and > that's just too expensive for us. So we use the monotone-like > new-workdir which allows us to save those build artifacts. > > So, that said, I ask again, am I missing something? Is there a better > way to do this? How do the kernel developers do this, surely they're > switching branches back and forth having to build in-between? Sure, if you want to keep the build tree around, you would probably not use branches. 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). 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. Junio? Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
