> -----Original Message----- > From: git-owner@xxxxxxxxxxxxxxx > [mailto:git-owner@xxxxxxxxxxxxxxx] On Behalf Of Linus Torvalds > Sent: Thursday, July 31, 2008 2:18 PM > single database for git, but wants to force a full clone for > each. Not to mention that in git, you'd normally not do 11 > clones to begin with, you'd just do 11 branches in one repo. > I have a question about this. I asked this awhile back and didn't really get any satisfactory answers except to use git-new-workdir, which makes git behave a lot like monotone. In our workflow, we do create branches for nearly everything, but we do find that we have a need to keep the build artifacts of those branches isolated from each other because rebuilding is expensive. IOW, we have this sort of workflow: git checkout A [work on A, build, test, do some commits] git checkout B [work on B, build, test, do some commits] git checkout A [work on A, re-build, test, do some commits] 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? > 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 > Cheers, Craig -- 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
