Git-new-workdir

Git-new-workdir

[Craig L. Ching]

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

Re: Git-new-workdir

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

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@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

RE: Git-new-workdir

[Craig L. Ching]

 

> From: Luciano Rocha [mailto:luciano@eurotux.com] 
> On Wed, May 21, 2008 at 01:21:22PM -0500, Craig L. Ching wrote:
> > Hi all,
> > 

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

> 
> 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.
> 
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.

> --
> Luciano Rocha <luciano@eurotux.com>
> Eurotux Informática, S.A. <http://www.eurotux.com/>
> 
> 

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

Cheers,
Craig

Re: Git-new-workdir

[Brandon Casey]

Luciano Rocha wrote:

> git clone server:/rep ~/master
> git clone -s ~/master build/abc
> git clone -s ~/master build/foo
> ...

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.

> The -s option should reduce disk-usage considerably.

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

RE: Git-new-workdir

[Craig L. Ching]

 

> From: Brandon Casey [mailto:casey@nrlssc.navy.mil] 
> 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.
> 
Yes, that's precisely what we want to do.  So according to your
experience, we're making the right choice then.

> 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.
> 
Ok, for us this would probably be rare, but good to know.

> 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).
> 
We'd like that too ;-)

> -brandon
> 
> 

Cheers,
Craig

Re: Git-new-workdir

[Brandon Casey]

Craig L. Ching wrote:
>  
> 
>> From: Brandon Casey [mailto:casey@nrlssc.navy.mil] 
>> 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.
>>
> Yes, that's precisely what we want to do.  So according to your
> experience, we're making the right choice then.

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

-brandon

RE: Git-new-workdir

[Craig L. Ching]

> From: Robert Anderson [mailto:rwa000@gmail.com] 
> 
> On Wed, May 21, 2008 at 11:21 AM, Craig L. Ching 
> <cching@mqsoftware.com> 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.  
> 
> 
> You haven't explained your issue very well.  
> 
> What does "keeping multiple builds around" mean?  Taken at 
> face value this is irrelevant to source control.  So you must 
> mean something else, but you haven't explained what.  I keep 
> multiple builds around by using separate build directories 
> which are not source controlled.  Whether or not I keep 
> multiple builds of a source tree just isn't relevant to my 
> source control whether it be CVS or git or whatever.  Perhaps 
> you mean "different variations of the same source tree" or 
> something like that, in which case "git seems to cut across 
> that need" seems like an absurd thing to say.
> 
> Can you give an actual scenario, and say how you use CVS in that case?
> 
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