On Thu, 31 Jul 2008 14:48:21 -0500 "Craig L. Ching" <cching@xxxxxxxxxxxxxx> wrote: > 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: Is there a problem using git-new-workdir? It sounds like it does exactly what you want. > 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? A decent build system will only compile the source files that actually changed when switching branches. Couple that with a compiler cache (such as ccache) and switching between branches in the kernel or git project usually isn't prohibitively time consuming. Sean -- 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
