Re: Git branches - confusing behavior

[Theodore Tso <tytso@mit.edu>]

On Sun, May 11, 2008 at 04:04:31PM +0300, Dima Kagan wrote:
> > The uncommitted changes survived the branch change and are still in the
> > working tree, in svn just like in git.
> > 
> 
> Yes, I am aware of that, except one rarely works in one directory on
> multiple svn branches, because the branches are not private. Git's
> branches can be private, so perhaps this behavior should be
> different from SVN?

So if you *want* to use separate working directories for different
branches, you can do that in git too.  Some people find that more
convenient.  Other people don't.  

Keep in mind, the other difference between git and svn is that until
commits are published, they can be freely altered.  So many developers
who use git tend to commit their changes on the "scratch branches",
and then if they need to modify them, use either "git commit --amend"
or "git commit --interactive" as necessary to modify the commits on
the branches until they are just the way they want them.

I will often have several different features "in progress" at
different times, and they are all on scratch branches.  By keeping
them all on scratch branches, I can test them by creating a new
scratch integration branch, and merge the various "in progress"
features together to see how they work together, then go back to the
individual feature branches to clean them up some more.   

When I'm satisified with a particular branch, I'll use "git rebase
master" to rebase the work so that it is based off of the head of the
development branch, and then do a fast forward merge to merge it into
to development branch.

> BTW, Is there a way to do 'svn checkout -b new_branch' into a new directory?

Not as a single step operation, no.  If you put the following in a
script, it will basically do what you want, though.

cp -rl $old_repo $new_repo
cd $new_repo
git checkout $new_branch

It does require that your editor save files by renaming the old file
out of the way to file~ and then writing file as a new file, instead
of opening the existing file and then doing an O_TRUNC (since that
will smash the file on the other repo), but as long as your editor is
hard link friendly, this should work just fine, with minimal disk
space cost.

Or you can just drop the hard link and just copy the whole repostory
using "cp -r" --- after all, svn is horribly wasteful of disk space,
with each repository taking twice the amount of space as the working
directory, and so if you're used to paying that disk overhead cost
with SVN, then presumably you won't mind paying that price with git.
There are smarter ways of working, though, if you don't mind altering
your work flow a little.

    	       		   	     	  - Ted