On 2008.07.31 13:09:09 -0700, Linus Torvalds wrote: > > > 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> Hum, I guess I'm just missing something and prepare to get flamed, but wouldn't you want that one to be bare? Otherwise, the other clones won't see all of the original repo's branches, right? Maybe even better: mkdir local-mirror cd local-mirror git --bare init git remote add -f --mirror origin <central-repo-over-network> A cronjob (or whatever) could keep the local mirror up-to-date and the other repos can fetch from there. Pushing would need to go to a different remote then though.. Humm... Maybe not worth the trouble for a bit of additional object sharing. Björn -- 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
