Git branches - confusing behavior

Git branches - confusing behavior

[Dima Kagan]

Hi,

I'm currently evaluating git for doing some local work without
depending on the main subversion server. I started with the following
steps:

> git-svn clone http://svn.test.org/test/trunk
> cd trunk
> git branch test_branch
> git checkout test_branch
> vi somefile

Now, when I run 'git status' I get:
# On branch test_branch
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   somefile
#
no changes added to commit (use "git add" and/or "git commit -a")

This is what I expect of course. However, when I execute 'git checkout
master', I get:
M       somefile
Switched to branch "master"

And after running 'git status' on master I get:
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   somefile
#
no changes added to commit (use "git add" and/or "git commit -a")

Basically I see that the same file I edited on the 'test_branch'
branch appears to be modified on the 'master' branch as well. This
behavior is unwanted, of course.

Can someone please tell me, what am doing wrong? Or is this git's
normal behavior?

Thanks in advance! 

Re: Git branches - confusing behavior

[Jakub Narebski]

Dima Kagan <dima.kagan@gmail.com> writes:

> I'm currently evaluating git for doing some local work without
> depending on the main subversion server. I started with the following
> steps:
> 
> > git-svn clone http://svn.test.org/test/trunk
> > cd trunk
> > git branch test_branch
> > git checkout test_branch
> > vi somefile
> 
> Now, when I run 'git status' I get:
> # On branch test_branch
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #
> #       modified:   somefile
> #
> no changes added to commit (use "git add" and/or "git commit -a")

And now you have 'somefile' in the working arew, which state isn't
saved anywhere git knows of.
 
> This is what I expect of course. However, when I execute 'git checkout
> master', I get:
> M       somefile
> Switched to branch "master"

Git tries hard to preserve your modifications.  If you don't want to
commit changes to test_branch, you can use git-stash to stash them
away.

Note that the above is possible only in the trivial merge case.
Otherwise you would need to use "git checkout -m" (to merge), or
"git checkout -f" (to force checkout, possibly losing changes).

> And after running 'git status' on master I get:
> # On branch master
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #
> #       modified:   somefile
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> Basically I see that the same file I edited on the 'test_branch'
> branch appears to be modified on the 'master' branch as well. This
> behavior is unwanted, of course.
>
> Can someone please tell me, what am doing wrong? Or is this git's
> normal behavior?

This is normal, and wanted, behavior.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Git branches - confusing behavior

[Dima Kagan]

Jakub Narebski wrote:
> Dima Kagan <dima.kagan@gmail.com> writes:
> 
>> I'm currently evaluating git for doing some local work without
>> depending on the main subversion server. I started with the following
>> steps:
>>
>>> git-svn clone http://svn.test.org/test/trunk
>>> cd trunk
>>> git branch test_branch
>>> git checkout test_branch
>>> vi somefile
>> Now, when I run 'git status' I get:
>> # On branch test_branch
>> # Changed but not updated:
>> #   (use "git add <file>..." to update what will be committed)
>> #
>> #       modified:   somefile
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
> 
> And now you have 'somefile' in the working arew, which state isn't
> saved anywhere git knows of.
>  
>> This is what I expect of course. However, when I execute 'git checkout
>> master', I get:
>> M       somefile
>> Switched to branch "master"
> 
> Git tries hard to preserve your modifications.  If you don't want to
> commit changes to test_branch, you can use git-stash to stash them
> away.
> 
> Note that the above is possible only in the trivial merge case.
> Otherwise you would need to use "git checkout -m" (to merge), or
> "git checkout -f" (to force checkout, possibly losing changes).
> 

So if I am working on more than one branch at a time I need to commit my changes every time before I do
'git checkout <branch>'?

>> And after running 'git status' on master I get:
>> # On branch master
>> # Changed but not updated:
>> #   (use "git add <file>..." to update what will be committed)
>> #
>> #       modified:   somefile
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Basically I see that the same file I edited on the 'test_branch'
>> branch appears to be modified on the 'master' branch as well. This
>> behavior is unwanted, of course.
>>
>> Can someone please tell me, what am doing wrong? Or is this git's
>> normal behavior?
> 
> This is normal, and wanted, behavior.
> 

That's a subjective point of view :) I'm coming from the SVN world and uncommitted changes on one branch don't affect other branches. Is there a way I can achieve this behavior with git?

Re: Git branches - confusing behavior

[David Symonds]

On Sun, May 11, 2008 at 9:58 PM, Dima Kagan <dima.kagan@gmail.com> wrote:

> That's a subjective point of view :) I'm coming from the SVN world and uncommitted changes on one branch don't affect other branches. Is there a way I can achieve this behavior with git?

If you *really* want SVN's behaviour of "branches", just copy your
whole working tree (including the .git directory) and start making
changes in that. Then they'll be completely separate and you can just
'cd' between them.


Dave.

Re: Git branches - confusing behavior

[Dima Kagan]

David Symonds wrote:
> On Sun, May 11, 2008 at 9:58 PM, Dima Kagan <dima.kagan@gmail.com> wrote:
> 
>> That's a subjective point of view :) I'm coming from the SVN world and uncommitted changes on one branch don't affect other branches. Is there a way I can achieve this behavior with git?
> 
> If you *really* want SVN's behaviour of "branches", just copy your
> whole working tree (including the .git directory) and start making
> changes in that. Then they'll be completely separate and you can just
> 'cd' between them.
> 
> 
> Dave.

What's the point of using git then? :) I like the way branches are created and switched in git, but I would like each branch to preserve it's own history of modifications. Is that too much to ask? :)

Re: Git branches - confusing behavior

[David Symonds]

On Sun, May 11, 2008 at 10:11 PM, Dima Kagan <dima.kagan@gmail.com> wrote:
> David Symonds wrote:
>> On Sun, May 11, 2008 at 9:58 PM, Dima Kagan <dima.kagan@gmail.com> wrote:
>>
>>> That's a subjective point of view :) I'm coming from the SVN world and uncommitted changes on one branch don't affect other branches. Is there a way I can achieve this behavior with git?
>>
>> If you *really* want SVN's behaviour of "branches", just copy your
>> whole working tree (including the .git directory) and start making
>> changes in that. Then they'll be completely separate and you can just
>> 'cd' between them.
>>
>>
>> Dave.
>
> What's the point of using git then? :) I like the way branches are created and switched in git, but I would like each branch to preserve it's own history of modifications. Is that too much to ask? :)

Preserving history is called "committing", which is how git branches
preserve their own history. You said you don't want to commit changes.
You can't have it both ways.  :-P


Dave.

Re: Git branches - confusing behavior

[Dima Kagan]

> On Sun, May 11, 2008 at 10:11 PM, Dima Kagan <dima.kagan@gmail.com> wrote:
>> David Symonds wrote:
>>> On Sun, May 11, 2008 at 9:58 PM, Dima Kagan <dima.kagan@gmail.com> wrote:
>>>
>>>> That's a subjective point of view :) I'm coming from the SVN world and uncommitted changes on one branch don't affect other branches. Is there a way I can achieve this behavior with git?
>>> If you *really* want SVN's behaviour of "branches", just copy your
>>> whole working tree (including the .git directory) and start making
>>> changes in that. Then they'll be completely separate and you can just
>>> 'cd' between them.
>>>
>>>
>>> Dave.
>> What's the point of using git then? :) I like the way branches are created and switched in git, but I would like each branch to preserve it's own history of modifications. Is that too much to ask? :)
> 
> Preserving history is called "committing", which is how git branches
> preserve their own history. You said you don't want to commit changes.
> You can't have it both ways.  :-P
> 
> 
> Dave.

Not quite. :) The current branch knows what files have been modified without committing the changes.
Why should other branches be aware of these changes until I commit them?

Re: Git branches - confusing behavior

[Steve Frécinaux]

On Sun, May 11, 2008 at 1:58 PM, Dima Kagan <dima.kagan@gmail.com> wrote:

 >  >> Basically I see that the same file I edited on the 'test_branch'
 >  >> branch appears to be modified on the 'master' branch as well. This
 >  >> behavior is unwanted, of course.
 >  >>
 >  >> Can someone please tell me, what am doing wrong? Or is this git's
 >  >> normal behavior?
 >  >
 >  > This is normal, and wanted, behavior.
 >  >
 >
 >  That's a subjective point of view :) I'm coming from the SVN world
and uncommitted changes on one branch don't affect other branches. Is
there a way I can achieve this behavior with git?

 There are several ways, actually.

 The one I prefer to use is to commit the modifications. Then, you can
 use git-reset HEAD^ to drop that temporary commit when you come back
 to this branch, or git-commit --amend to modify it.

 Always keep in mind that in git's world, history is not set in stone,
 you can always modify previous commits, reorder them or merge them, as
 long as you have not pushed them to your public repository (in your
 case, the SVN one).

Re: Git branches - confusing behavior

[Dima Kagan]

> On Sun, May 11, 2008 at 1:58 PM, Dima Kagan <dima.kagan@gmail.com> wrote:
> 
>>  >> Basically I see that the same file I edited on the 'test_branch'
>>  >> branch appears to be modified on the 'master' branch as well. This
>>  >> behavior is unwanted, of course.
>>  >>
>>  >> Can someone please tell me, what am doing wrong? Or is this git's
>>  >> normal behavior?
>>  >
>>  > This is normal, and wanted, behavior.
>>  >
>>
>>  That's a subjective point of view :) I'm coming from the SVN world and uncommitted changes on one branch don't affect other branches. Is there a way I can achieve this behavior with git?
> 
> There are several ways, actually.
> 
> The one I prefer to use is to commit the modifications. Then, you can
> use git-reset HEAD^ to drop that temporary commit when you come back
> to this branch, or git-commit --amend to modify it.
> 
> Always keep in mind that in git's world, history is not set in stone,
> you can always modify previous commits, reorder them or merge them, as
> long as you have not pushed them to your public repository (in your
> case, the SVN one).

Hi!
Thanks for these little tips.

I understand that git is very powerful, however some things are hard to grasp when switching from SVN. Perhaps I should overview my workflow to see how it can benefit from git, despite these differences.

Re: Git branches - confusing behavior

[Jakub Narebski]

Dima Kagan wrote:
> Jakub Narebski wrote:
>> Dima Kagan <dima.kagan@gmail.com> writes:

[...]
> So if I am working on more than one branch at a time I need to commit
> my changes every time before I do 'git checkout <branch>'?
[...]
Not necessary, see below (and it is not necessary bad).

>>> Basically I see that the same file I edited on the 'test_branch'
>>> branch appears to be modified on the 'master' branch as well. This
>>> behavior is unwanted, of course.
>>>
>>> Can someone please tell me, what am doing wrong? Or is this git's
>>> normal behavior?
>> 
>> This is normal, and wanted, behavior.
 
> That's a subjective point of view :) I'm coming from the SVN world and
> uncommitted changes on one branch don't affect other branches. Is
> there a way I can achieve this behavior with git?  

How would you want git to behave, with "git checkout <branch>" changing 
branches _in place_, in single working area?  Besides, current 
behavior, together with "git checkout -m" option, allows to change 
branches when you have realized (after making some changes) that you 
are on wrong branch...


There are few possible solutions:

1. Save state before switching branches

1.1. You can simply commit changes before switching branch, perhaps with
"(WIP)" (work in progress) in the commit message.  Then, when you go 
back to the branch, you can continue your work, and simply --amend (as 
in "git commit --amend" a commit.

1.2. You can use git-stash to save state of your working area (working 
directory) _and_ index, change branches, and when going back to branch 
restore state using "git stash apply". I think you can save state even 
during not resolved merge.

1.3. If you use patch management interface on top of Git, like StGit
(or Guilt), you can simply "stg refresh" a patch, then change branches.  
When returning to branch, use refresh and/or edit, then create new 
patch if you think current is finished (you can always go back...).


2. Use separate working for differen branches: this is what Bazaar does, 
what Mercurial does by default without 'localbranch' extension, and I 
think also what Subversion does.   Take a look at contrib/workdir
on how to manage multiple working areas with single repository; the 
core.workdir and --working-dir could also be of help.

Note that in this case you have to take care to not have the same branch 
checked out to two (or more) different working areas, to not stomp on 
your changes, and to avoid confusion.


Final note: you would work better learning SCM "the git way", and not to 
rely on Subversion bad habits (yes, I know that bad CVS habits are 
worse...) ;-)

-- 
Jakub Narebski
Poland

Re: Git branches - confusing behavior

[Dima Kagan]

>> Basically I see that the same file I edited on the 'test_branch'
>> branch appears to be modified on the 'master' branch as well. This
>> behavior is unwanted, of course.
>>
>> Can someone please tell me, what am doing wrong? Or is this git's
>> normal behavior?
> 

I just realized that this behavior is even more confusing.
If I commit the file on 'test_branch' and only then 'git checkout master' the changes are not visible on 'master' until I merge. So why should 'master' be affected by uncommitted changes on some branch???

Re: Git branches - confusing behavior

[Björn Steinbrink]

On 2008.05.11 15:33:21 +0300, Dima Kagan wrote:
> >> Basically I see that the same file I edited on the 'test_branch'
> >> branch appears to be modified on the 'master' branch as well. This
> >> behavior is unwanted, of course.
> >>
> >> Can someone please tell me, what am doing wrong? Or is this git's
> >> normal behavior?
> > 
> 
> I just realized that this behavior is even more confusing.  If I
> commit the file on 'test_branch' and only then 'git checkout master'
> the changes are not visible on 'master' until I merge. So why should
> 'master' be affected by uncommitted changes on some branch???

Uncommitted changes are not on any branch, they are in your working tree
and/or your index. And actually, SVN does the exact same thing.

# Create a SVN repository with trunk/ and branches/
# ----
$ mkdir svn
$ cd svn
$ svnadmin create repo
$ export REPO="file://$PWD/repo"
$ svn co $REPO wc
Checked out revision 0.
$ cd wc
$ svn mkdir trunk branches
A         trunk
A         branches
$ svn commit -m init
Adding         branches
Adding         trunk

Committed revision 1.
$ svn switch $REPO/trunk
D    trunk
D    branches
Updated to revision 1.


# Create some content in trunk
# ----
$ echo 123 > testfile
$ svn add testfile
A         testfile
$ svn commit -m test
Adding         testfile
Transmitting file data .
Committed revision 2.


# Create a branch
# ----
$ svn cp $REPO/trunk $REPO/branches/b1 -m branch

Committed revision 3.


# Produce some uncommitted changes on trunk
# ----
$ echo 456 > testfile
$ svn st
M      testfile
$ svn diff
Index: testfile
===================================================================
--- testfile    (revision 2)
+++ testfile    (working copy)
@@ -1 +1 @@
-123
+456


# Switch to the branch
# ----
$ svn switch $REPO/branches/b1
At revision 3.
$ svn st
M      testfile
$ svn diff
Index: testfile
===================================================================
--- testfile    (revision 3)
+++ testfile    (working copy)
@@ -1 +1 @@
-123
+456


The uncommitted changes survived the branch change and are still in the
working tree, in svn just like in git.

Björn

Re: Git branches - confusing behavior

[Dima Kagan]

Björn Steinbrink wrote:
> On 2008.05.11 15:33:21 +0300, Dima Kagan wrote:
>>>> Basically I see that the same file I edited on the 'test_branch'
>>>> branch appears to be modified on the 'master' branch as well. This
>>>> behavior is unwanted, of course.
>>>>
>>>> Can someone please tell me, what am doing wrong? Or is this git's
>>>> normal behavior?
>> I just realized that this behavior is even more confusing.  If I
>> commit the file on 'test_branch' and only then 'git checkout master'
>> the changes are not visible on 'master' until I merge. So why should
>> 'master' be affected by uncommitted changes on some branch???
> 
> Uncommitted changes are not on any branch, they are in your working tree
> and/or your index. And actually, SVN does the exact same thing.
> 
> # Create a SVN repository with trunk/ and branches/
> # ----
> $ mkdir svn
> $ cd svn
> $ svnadmin create repo
> $ export REPO="file://$PWD/repo"
> $ svn co $REPO wc
> Checked out revision 0.
> $ cd wc
> $ svn mkdir trunk branches
> A         trunk
> A         branches
> $ svn commit -m init
> Adding         branches
> Adding         trunk
> 
> Committed revision 1.
> $ svn switch $REPO/trunk
> D    trunk
> D    branches
> Updated to revision 1.
> 
> 
> # Create some content in trunk
> # ----
> $ echo 123 > testfile
> $ svn add testfile
> A         testfile
> $ svn commit -m test
> Adding         testfile
> Transmitting file data .
> Committed revision 2.
> 
> 
> # Create a branch
> # ----
> $ svn cp $REPO/trunk $REPO/branches/b1 -m branch
> 
> Committed revision 3.
> 
> 
> # Produce some uncommitted changes on trunk
> # ----
> $ echo 456 > testfile
> $ svn st
> M      testfile
> $ svn diff
> Index: testfile
> ===================================================================
> --- testfile    (revision 2)
> +++ testfile    (working copy)
> @@ -1 +1 @@
> -123
> +456
> 
> 
> # Switch to the branch
> # ----
> $ svn switch $REPO/branches/b1
> At revision 3.
> $ svn st
> M      testfile
> $ svn diff
> Index: testfile
> ===================================================================
> --- testfile    (revision 3)
> +++ testfile    (working copy)
> @@ -1 +1 @@
> -123
> +456
> 
> 
> The uncommitted changes survived the branch change and are still in the
> working tree, in svn just like in git.
> 
> Björn

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?

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

Re: Git branches - confusing behavior

[Björn Steinbrink]

On 2008.05.11 16:04:31 +0300, Dima Kagan wrote:
> Björn Steinbrink wrote:
> > On 2008.05.11 15:33:21 +0300, Dima Kagan wrote:
> >>>> Basically I see that the same file I edited on the 'test_branch'
> >>>> branch appears to be modified on the 'master' branch as well. This
> >>>> behavior is unwanted, of course.
> >>>>
> >>>> Can someone please tell me, what am doing wrong? Or is this git's
> >>>> normal behavior?
> >> I just realized that this behavior is even more confusing.  If I
> >> commit the file on 'test_branch' and only then 'git checkout master'
> >> the changes are not visible on 'master' until I merge. So why should
> >> 'master' be affected by uncommitted changes on some branch???
> > 
> > Uncommitted changes are not on any branch, they are in your working tree
> >
[example removed]
> > 
> > 
> > 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.

I always did that, the working copy _is_ private even in svn, so messing
with that was not a problem there either.

> Git's branches can be private, so perhaps this behavior should be
> different from SVN?

No. Uncommitted changes are, well, uncommitted. They don't belong to any
branch yet. A branch is not some structure that contains history in
itself. A branch just points to a commit, and the commits, with their
parent-child relations, form the actual history. The index and working
tree are not part of a branch.

Changing that would even break a workflow that is rather common for me.
I start working on something that is either just experimental or assumed
to be a very small change. Then I realize that the change is worth
keeping and/or too big and deserves its own branch. At that point, I can
just do "git checkout -b new_branch", and pretend that I started working
on that branch right from the start. With your proposed change, I would
need some extra command to transfer the work in progress from the old
branch to the new branch.

If I ever want to switch to another branch and not keep the changes in
my working tree and index, I stash them away or create a temporary
commit, which I later amend. That's a use-case that comes up rather
seldom though (for me at least).

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

There's a script (new-working-tree or so) in contrib/ that can create a
second working tree for a given repo, but I usually prefer to just clone
my repo locally. In the second repo, I can then switch branches as much
as I like ;-)

Björn

Re: Git branches - confusing behavior

[Dima Kagan]

Björn Steinbrink wrote:
 > No. Uncommitted changes are, well, uncommitted. They don't belong to any
> branch yet. A branch is not some structure that contains history in
> itself. A branch just points to a commit, and the commits, with their
> parent-child relations, form the actual history. The index and working
> tree are not part of a branch.
> 
> Changing that would even break a workflow that is rather common for me.
> I start working on something that is either just experimental or assumed
> to be a very small change. Then I realize that the change is worth
> keeping and/or too big and deserves its own branch. At that point, I can
> just do "git checkout -b new_branch", and pretend that I started working
> on that branch right from the start. With your proposed change, I would
> need some extra command to transfer the work in progress from the old
> branch to the new branch.
> 
> If I ever want to switch to another branch and not keep the changes in
> my working tree and index, I stash them away or create a temporary
> commit, which I later amend. That's a use-case that comes up rather
> seldom though (for me at least).
> 
> Björn

My proposed change shouldn't necessarily break the described workflow. Git can keep the current behavior for new branches, but automatically 'stash' the changes when checking-out an existing branch. At least having an optional parameter for "auto-stashing" will be nice.

What do you think of that?

Re: Git branches - confusing behavior

[Patrick Aljord]

On Sun, May 11, 2008 at 8:39 AM, Dima Kagan <dima.kagan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> My proposed change shouldn't necessarily break the described workflow. Git can keep the current behavior for new branches, but automatically 'stash' the changes when checking-out an existing branch. At least having an optional parameter for "auto-stashing" will be nice.
>
> What do you think of that?

you can do just that with an alias, in .git/config add:

[alias]
        auto-stash = !git stash && git checkout $1

then type "git auto-stash master" or "git auto-stash some_branch" and
it should stash and checkout the branch.

Cheers,

Pat

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Git for human beings" group.
To post to this group, send email to git-users-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to git-users-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/git-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Git branches - confusing behavior

[Teemu Likonen]

Dima Kagan wrote (2008-05-11 16:39 +0300):

> My proposed change shouldn't necessarily break the described workflow.
> Git can keep the current behavior for new branches, but automatically
> 'stash' the changes when checking-out an existing branch. At least
> having an optional parameter for "auto-stashing" will be nice.
> 
> What do you think of that?

With the fact that Git's branches are just pointers to a commit (and
therefore to a history) and that you can checkout anything that refers
to a commit (branches, tags, SHA1's, relative pointers like
HEAD@{30.minutes.ago}^2~3) I think such auto-stashing would be make
things pretty complicated and unintuitive in the big picture. The user
interface remains simpler if we just learn to use "git stash" to
temporarily put away changes in the index and the working directory when
we need to.

Re: Git branches - confusing behavior

[Miles Bader]

Dima Kagan <dima.kagan@gmail.com> writes:
> My proposed change shouldn't necessarily break the described
> workflow. Git can keep the current behavior for new branches, but
> automatically 'stash' the changes when checking-out an existing
> branch.

It's not going to happen, at least by default.  Many people already rely
on -- and like -- the current behavior, which is often quite convenient
(edit some files and then realize "oh, I should commit these to another
branch"... no prob! :-).

Occasionally it is inconvenient, of course, but git offers mechanisms to
use in such cases, most notably "git stash" (and of course super-cheap
local branches which can be amended or even deleted later).

I think the real problem here is that you haven't quite gotten used
to git yet.

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: Git branches - confusing behavior

[Theodore Tso]

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

Re: Git branches - confusing behavior

[Matt Seitz (matseitz)]

On May 11, 3:58 am, mitya <dima.ka...@gmail.com> wrote:
> I started with the following steps:
> 
> > git-svn clonehttp://svn.test.org/test/trunk
> > cd trunk
> > git branch test_branch
> > git checkout test_branch
> > vi somefile
> 
> However, when I execute 'git checkout master', I get:
> M       somefile
> Switched to branch "master"
> 
> Basically I see that the same file I edited on the 'test_branch'
> branch appears to be modified on the 'master' branch as well. 

I was also confused by this behavior.  I think this is a documentation issue.  In the "man" page for "git-checkout", the "Description" section says:

"...this command switches branches by updating the index and working tree to reflect the specified branch...".

This led me to believe that all files in the working tree would be updated to match the last commit in the specified branch.  The "Description" section doesn't mention any exceptions, such as files that have been modified but not committed in the current branch.  

There are some clues that this is the intended behavior in the descriptions of the "-f" and "-m" options, and in the "After working in the wrong branch..." example.  But it was not clear to me from reading the "man" page (and the "gittutorial" and the "Git User's Guide") that this behavior was correct and intended. 

I think it would be helpful in the "Description" section of the "man" page to elaborate on how git updates the working tree to reflect the specified branch.  This could include documenting the default handling of files that have been modified in the current branch.  A rationale for the behavior would also be helpful.  This might have prevented my confusion when first encountering this issue.
  
--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.