On Wed, May 21, 2008 at 01:21:22PM -0500, Craig L. Ching wrote: > Hi all, > > I'm a bit of a newbie to Git, but I have started using it in earnest for > the past couple of months. I had asked on IRC about a potential problem > I saw with git and how it fit into our workflow. We currently use CVS > and have used it for the past ten years. A lot of us have grown > accustomed to keeping multiple builds around for different things, e.g. > defects we're working on, new features, etc., we do a lot of task > switching and very rarely can we work on something start to finish > without being interrupted with something else. The normal workflow of > git seems to cut across that need to keep many builds around. > Generally, building our software is not trivial and takes a fair amount > of time, so just "git checkout" out a new branch and rebuilding is not > really an option for us. I jumped on IRC while back and the contrib > git-new-workdir was sugggested, but with the caveat that I should try > and think outside the box before I adopted git-new-workdir. So, I come > here, after using Git for a couple of months and not seeing a way around > this, asking if I'm missing something? Should I be using > git-new-workdir? Or is there a better way that I have yet to see? I'm > sure the kernel developers must have this need as well, so it's quite > possible I'm missing something. I appreciate all feedback! Personally, I'd clone a local rep for each build, with the -s option to clone. Something like: git clone server:/rep ~/master git clone -s ~/master build/abc git clone -s ~/master build/foo ... The -s option should reduce disk-usage considerably. -- Luciano Rocha <luciano@xxxxxxxxxxx> Eurotux Informática, S.A. <http://www.eurotux.com/>
Attachment:
pgpCvmixJxQOK.pgp
Description: PGP signature
