Git-new-workdir

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!

Cheers, Craig

On Wed, May 21, 2008 at 01:21:22PM -0500, Craig L. Ching wrote:

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.

[stuff about why we want to use git-new-workdir]

Yeah, I neglected to mention that the other good thing about git-new-workdir is that the origin is set to the origin of the remote repository so to push changes to our central repository, you only need one push.  Otherwise you have to push twice, right?  Well now (thinking out loud here), maybe you don't.  That was the impression I got from the IRC conversation, but maybe you could just push from the original clone?  Still, seems easier if all the shared repositories and the original clone pushed to the same place, at least for us.

Thanks for the feedback, it's making me think about the problem ;-)

Cheers, Craig

Luciano Rocha wrote:

Don't do that without first doing

    git config gc.pruneExpire never

to disable pruning loose objects if there is any chance that any will be created. Better to be safe, and prune manually using the example in the prune documentation.

It won't be any less than what git-new-workdir would produce. Actually, git-new-workdir could provide more space savings since there is only a single repository so new objects created by development in any of the new work directories would be available to all others. This is getting a little nit-picky, basically space usage for the two options is nil.

My take on it...

If you want to have _multiple_different_ branches checked out from the _same_ repository, and do development in all of them, then git-new-workdir is the right choice.

If you want to have the _same_branch_ checked out in multiple work directories, then cloning with -s is what you want. In this case I assume development will be performed in the original repo, and the clones will do a pull to update.

Personally, I have found the git-new-workdir script to satisfy any need which caused me to even think about cloning with -s. I am hoping the functionality of git-new-workdir will be folded into git porcelain at some point (ahem J Schindelin).

-brandon

Yes, that's precisely what we want to do. So according to your experience, we're making the right choice then.

Ok, for us this would probably be rare, but good to know.

We'd like that too ;-)

Cheers, Craig

Craig L. Ching wrote:

Yes. I feel more confident after reading your reply to Robert where you described your use-case more thoroughly.

-brandon

Sure, what I mean is that you checkout a branch, the workspace reflects the state of that branch. If you do a build in the workspace, the build artifacts match up with the source that's in the workspace. If you then checkout a new branch, it's unlikely that the source reflects the build artifacts any more.

Here's how we did it in CVS. Any feature or defect got it's own branch, no matter how trivial it was (yes, it was very painful with CVS, but the benefits outweighed the pain. Moving to Git is very easy for us since we already have the "branch for everything" mindset ;-) ). So, say you have two defects, A and B. We'd create two separate branches named after the defects, so two branches named A and B. Then we'd do:

Cd ~/dev/ Mkdir A && cd A && cvs co -r A && make Mkdir B && cd B && cvs co -r B && make

That way we'd have two separate workspaces where the build artifacts match with the source. Now, I suppose you could suggest we change our build procedure so that it puts the build artifacts outside of the VCS workspace, i.e. our makefiles could "git branch" and create a directory for those build artifacts outside of the source workspace? That might work, I'd have to think about it a bit more, but I know for our java sources that might be a problem with a lot of java build tool conventions, e.g. maven puts the build artifacts in the same top-level directory that contains the sources.

Cheers, Craig