{"thread":{"id":"13474","subject":"Git branches - confusing behavior","startedAt":"2008-05-11T11:31:06Z","lastAt":"2008-05-12T07:49:47Z","messageCount":19,"participants":["Dima Kagan","Jakub Narebski","David Symonds","Steve Frécinaux","Björn Steinbrink","Theodore Tso","Patrick Aljord","Teemu Likonen","Miles Bader"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76600","messageId":"4826D8FA.30305@gmail.com","threadId":"13474","inReplyTo":null,"subject":"Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T11:31:06Z","receivedAt":"2008-05-11T11:31:06Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":"Hi,\n\nI'm currently evaluating git for doing some local work without\ndepending on the main subversion server. I started with the following\nsteps:\n\n> git-svn clone http://svn.test.org/test/trunk\n> cd trunk\n> git branch test_branch\n> git checkout test_branch\n> vi somefile\n\nNow, when I run 'git status' I get:\n# On branch test_branch\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: somefile\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nThis is what I expect of course. However, when I execute 'git checkout\nmaster', I get:\nM somefile\nSwitched to branch \"master\"\n\nAnd after running 'git status' on master I get:\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: somefile\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nBasically I see that the same file I edited on the 'test_branch'\nbranch appears to be modified on the 'master' branch as well. This\nbehavior is unwanted, of course.\n\nCan someone please tell me, what am doing wrong? Or is this git's\nnormal behavior?\n\nThanks in advance! \n"},{"id":"76601","messageId":"m31w495apd.fsf@localhost.localdomain","threadId":"13474","inReplyTo":"4826D8FA.30305@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-11T11:42:10Z","receivedAt":"2008-05-11T11:42:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dima Kagan writes:\n\n> I'm currently evaluating git for doing some local work without\n> depending on the main subversion server. I started with the following\n> steps:\n> \n> > git-svn clone http://svn.test.org/test/trunk\n> > cd trunk\n> > git branch test_branch\n> > git checkout test_branch\n> > vi somefile\n> \n> Now, when I run 'git status' I get:\n> # On branch test_branch\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> #\n> # modified: somefile\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nAnd now you have 'somefile' in the working arew, which state isn't\nsaved anywhere git knows of.\n \n> This is what I expect of course. However, when I execute 'git checkout\n> master', I get:\n> M somefile\n> Switched to branch \"master\"\n\nGit tries hard to preserve your modifications. If you don't want to\ncommit changes to test_branch, you can use git-stash to stash them\naway.\n\nNote that the above is possible only in the trivial merge case.\nOtherwise you would need to use \"git checkout -m\" (to merge), or\n\"git checkout -f\" (to force checkout, possibly losing changes).\n\n> And after running 'git status' on master I get:\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> #\n> # modified: somefile\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> \n> Basically I see that the same file I edited on the 'test_branch'\n> branch appears to be modified on the 'master' branch as well. This\n> behavior is unwanted, of course.\n>\n> Can someone please tell me, what am doing wrong? Or is this git's\n> normal behavior?\n\nThis is normal, and wanted, behavior.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"76603","messageId":"4826DF6A.2070306@gmail.com","threadId":"13474","inReplyTo":"m31w495apd.fsf@localhost.localdomain","subject":"Re: Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T11:58:34Z","receivedAt":"2008-05-11T11:58:34Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":"\n\nJakub Narebski wrote:\n> Dima Kagan writes:\n> \n>> I'm currently evaluating git for doing some local work without\n>> depending on the main subversion server. I started with the following\n>> steps:\n>>\n>>> git-svn clone http://svn.test.org/test/trunk\n>>> cd trunk\n>>> git branch test_branch\n>>> git checkout test_branch\n>>> vi somefile\n>> Now, when I run 'git status' I get:\n>> # On branch test_branch\n>> # Changed but not updated:\n>> # (use \"git add ...\" to update what will be committed)\n>> #\n>> # modified: somefile\n>> #\n>> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> \n> And now you have 'somefile' in the working arew, which state isn't\n> saved anywhere git knows of.\n> \n>> This is what I expect of course. However, when I execute 'git checkout\n>> master', I get:\n>> M somefile\n>> Switched to branch \"master\"\n> \n> Git tries hard to preserve your modifications. If you don't want to\n> commit changes to test_branch, you can use git-stash to stash them\n> away.\n> \n> Note that the above is possible only in the trivial merge case.\n> Otherwise you would need to use \"git checkout -m\" (to merge), or\n> \"git checkout -f\" (to force checkout, possibly losing changes).\n> \n\nSo if I am working on more than one branch at a time I need to commit my changes every time before I do\n'git checkout '?\n\n>> And after running 'git status' on master I get:\n>> # On branch master\n>> # Changed but not updated:\n>> # (use \"git add ...\" to update what will be committed)\n>> #\n>> # modified: somefile\n>> #\n>> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>>\n>> Basically I see that the same file I edited on the 'test_branch'\n>> branch appears to be modified on the 'master' branch as well. This\n>> behavior is unwanted, of course.\n>>\n>> Can someone please tell me, what am doing wrong? Or is this git's\n>> normal behavior?\n> \n> This is normal, and wanted, behavior.\n> \n\nThat'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?\n"},{"id":"76604","messageId":"ee77f5c20805110506i58dc735fqb6f4258dbb67bf27@mail.gmail.com","threadId":"13474","inReplyTo":"4826DF6A.2070306@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-05-11T12:06:19Z","receivedAt":"2008-05-11T12:06:19Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Sun, May 11, 2008 at 9:58 PM, Dima Kagan wrote:\n\n> 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?\n\nIf you *really* want SVN's behaviour of \"branches\", just copy your\nwhole working tree (including the .git directory) and start making\nchanges in that. Then they'll be completely separate and you can just\n'cd' between them.\n\n\nDave.\n"},{"id":"76605","messageId":"4826E255.6030005@gmail.com","threadId":"13474","inReplyTo":"ee77f5c20805110506i58dc735fqb6f4258dbb67bf27@mail.gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T12:11:01Z","receivedAt":"2008-05-11T12:11:01Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":"David Symonds wrote:\n> On Sun, May 11, 2008 at 9:58 PM, Dima Kagan wrote:\n> \n>> 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?\n> \n> If you *really* want SVN's behaviour of \"branches\", just copy your\n> whole working tree (including the .git directory) and start making\n> changes in that. Then they'll be completely separate and you can just\n> 'cd' between them.\n> \n> \n> Dave.\n\nWhat'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? :)\n"},{"id":"76606","messageId":"ee77f5c20805110513k4d34c8f8m83dd9d75a8ec47f4@mail.gmail.com","threadId":"13474","inReplyTo":"4826E255.6030005@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-05-11T12:13:36Z","receivedAt":"2008-05-11T12:13:36Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Sun, May 11, 2008 at 10:11 PM, Dima Kagan wrote:\n> David Symonds wrote:\n>> On Sun, May 11, 2008 at 9:58 PM, Dima Kagan wrote:\n>>\n>>> 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?\n>>\n>> If you *really* want SVN's behaviour of \"branches\", just copy your\n>> whole working tree (including the .git directory) and start making\n>> changes in that. Then they'll be completely separate and you can just\n>> 'cd' between them.\n>>\n>>\n>> Dave.\n>\n> 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? :)\n\nPreserving history is called \"committing\", which is how git branches\npreserve their own history. You said you don't want to commit changes.\nYou can't have it both ways. :-P\n\n\nDave.\n"},{"id":"76607","messageId":"4826E3DE.5020506@gmail.com","threadId":"13474","inReplyTo":"ee77f5c20805110513k4d34c8f8m83dd9d75a8ec47f4@mail.gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T12:17:34Z","receivedAt":"2008-05-11T12:17:34Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":"> On Sun, May 11, 2008 at 10:11 PM, Dima Kagan wrote:\n>> David Symonds wrote:\n>>> On Sun, May 11, 2008 at 9:58 PM, Dima Kagan wrote:\n>>>\n>>>> 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?\n>>> If you *really* want SVN's behaviour of \"branches\", just copy your\n>>> whole working tree (including the .git directory) and start making\n>>> changes in that. Then they'll be completely separate and you can just\n>>> 'cd' between them.\n>>>\n>>>\n>>> Dave.\n>> 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? :)\n> \n> Preserving history is called \"committing\", which is how git branches\n> preserve their own history. You said you don't want to commit changes.\n> You can't have it both ways. :-P\n> \n> \n> Dave.\n\nNot quite. :) The current branch knows what files have been modified without committing the changes.\nWhy should other branches be aware of these changes until I commit them?\n"},{"id":"76608","messageId":"f35478f50805110520n444402a5u86c498d91f82941c@mail.gmail.com","threadId":"13474","inReplyTo":"4826DF6A.2070306@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Steve Frécinaux","fromEmail":"nudrema@gmail.com","sentAt":"2008-05-11T12:20:08Z","receivedAt":"2008-05-11T12:20:08Z","isPatch":false,"sender":{"key":"nudrema@gmail.com","avatar":null},"body":"On Sun, May 11, 2008 at 1:58 PM, Dima Kagan wrote:\n\n > >> Basically I see that the same file I edited on the 'test_branch'\n > >> branch appears to be modified on the 'master' branch as well. This\n > >> behavior is unwanted, of course.\n > >>\n > >> Can someone please tell me, what am doing wrong? Or is this git's\n > >> normal behavior?\n > >\n > > This is normal, and wanted, behavior.\n > >\n >\n > That's a subjective point of view :) I'm coming from the SVN world\nand uncommitted changes on one branch don't affect other branches. Is\nthere a way I can achieve this behavior with git?\n\n There are several ways, actually.\n\n The one I prefer to use is to commit the modifications. Then, you can\n use git-reset HEAD^ to drop that temporary commit when you come back\n to this branch, or git-commit --amend to modify it.\n\n Always keep in mind that in git's world, history is not set in stone,\n you can always modify previous commits, reorder them or merge them, as\n long as you have not pushed them to your public repository (in your\n case, the SVN one).\n"},{"id":"76609","messageId":"4826E4BA.9080506@gmail.com","threadId":"13474","inReplyTo":"f35478f50805110513h15aa462bs9ee35ed4738d3009@mail.gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T12:21:14Z","receivedAt":"2008-05-11T12:21:14Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":"> On Sun, May 11, 2008 at 1:58 PM, Dima Kagan wrote:\n> \n>> >> Basically I see that the same file I edited on the 'test_branch'\n>> >> branch appears to be modified on the 'master' branch as well. This\n>> >> behavior is unwanted, of course.\n>> >>\n>> >> Can someone please tell me, what am doing wrong? Or is this git's\n>> >> normal behavior?\n>> >\n>> > This is normal, and wanted, behavior.\n>> >\n>>\n>> 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?\n> \n> There are several ways, actually.\n> \n> The one I prefer to use is to commit the modifications. Then, you can\n> use git-reset HEAD^ to drop that temporary commit when you come back\n> to this branch, or git-commit --amend to modify it.\n> \n> Always keep in mind that in git's world, history is not set in stone,\n> you can always modify previous commits, reorder them or merge them, as\n> long as you have not pushed them to your public repository (in your\n> case, the SVN one).\n\nHi!\nThanks for these little tips.\n\nI 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.\n"},{"id":"76610","messageId":"4826E791.7030407@gmail.com","threadId":"13474","inReplyTo":"m31w495apd.fsf@localhost.localdomain","subject":"Re: Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T12:33:21Z","receivedAt":"2008-05-11T12:33:21Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":">> Basically I see that the same file I edited on the 'test_branch'\n>> branch appears to be modified on the 'master' branch as well. This\n>> behavior is unwanted, of course.\n>>\n>> Can someone please tell me, what am doing wrong? Or is this git's\n>> normal behavior?\n> \n\nI just realized that this behavior is even more confusing.\nIf 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???\n"},{"id":"76611","messageId":"20080511125722.GA22075@atjola.homenet","threadId":"13474","inReplyTo":"4826E791.7030407@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-05-11T12:57:22Z","receivedAt":"2008-05-11T12:57:22Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.05.11 15:33:21 +0300, Dima Kagan wrote:\n> >> Basically I see that the same file I edited on the 'test_branch'\n> >> branch appears to be modified on the 'master' branch as well. This\n> >> behavior is unwanted, of course.\n> >>\n> >> Can someone please tell me, what am doing wrong? Or is this git's\n> >> normal behavior?\n> > \n> \n> I just realized that this behavior is even more confusing. If I\n> commit the file on 'test_branch' and only then 'git checkout master'\n> the changes are not visible on 'master' until I merge. So why should\n> 'master' be affected by uncommitted changes on some branch???\n\nUncommitted changes are not on any branch, they are in your working tree\nand/or your index. And actually, SVN does the exact same thing.\n\n# Create a SVN repository with trunk/ and branches/\n# ----\n$ mkdir svn\n$ cd svn\n$ svnadmin create repo\n$ export REPO=\"file://$PWD/repo\"\n$ svn co $REPO wc\nChecked out revision 0.\n$ cd wc\n$ svn mkdir trunk branches\nA trunk\nA branches\n$ svn commit -m init\nAdding branches\nAdding trunk\n\nCommitted revision 1.\n$ svn switch $REPO/trunk\nD trunk\nD branches\nUpdated to revision 1.\n\n\n# Create some content in trunk\n# ----\n$ echo 123 > testfile\n$ svn add testfile\nA testfile\n$ svn commit -m test\nAdding testfile\nTransmitting file data .\nCommitted revision 2.\n\n\n# Create a branch\n# ----\n$ svn cp $REPO/trunk $REPO/branches/b1 -m branch\n\nCommitted revision 3.\n\n\n# Produce some uncommitted changes on trunk\n# ----\n$ echo 456 > testfile\n$ svn st\nM testfile\n$ svn diff\nIndex: testfile\n===================================================================\n--- testfile (revision 2)\n+++ testfile (working copy)\n@@ -1 +1 @@\n-123\n+456\n\n\n# Switch to the branch\n# ----\n$ svn switch $REPO/branches/b1\nAt revision 3.\n$ svn st\nM testfile\n$ svn diff\nIndex: testfile\n===================================================================\n--- testfile (revision 3)\n+++ testfile (working copy)\n@@ -1 +1 @@\n-123\n+456\n\n\nThe uncommitted changes survived the branch change and are still in the\nworking tree, in svn just like in git.\n\nBjörn\n"},{"id":"76612","messageId":"4826EEDF.4010404@gmail.com","threadId":"13474","inReplyTo":"20080511125722.GA22075@atjola.homenet","subject":"Re: Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T13:04:31Z","receivedAt":"2008-05-11T13:04:31Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":"Björn Steinbrink wrote:\n> On 2008.05.11 15:33:21 +0300, Dima Kagan wrote:\n>>>> Basically I see that the same file I edited on the 'test_branch'\n>>>> branch appears to be modified on the 'master' branch as well. This\n>>>> behavior is unwanted, of course.\n>>>>\n>>>> Can someone please tell me, what am doing wrong? Or is this git's\n>>>> normal behavior?\n>> I just realized that this behavior is even more confusing. If I\n>> commit the file on 'test_branch' and only then 'git checkout master'\n>> the changes are not visible on 'master' until I merge. So why should\n>> 'master' be affected by uncommitted changes on some branch???\n> \n> Uncommitted changes are not on any branch, they are in your working tree\n> and/or your index. And actually, SVN does the exact same thing.\n> \n> # Create a SVN repository with trunk/ and branches/\n> # ----\n> $ mkdir svn\n> $ cd svn\n> $ svnadmin create repo\n> $ export REPO=\"file://$PWD/repo\"\n> $ svn co $REPO wc\n> Checked out revision 0.\n> $ cd wc\n> $ svn mkdir trunk branches\n> A trunk\n> A branches\n> $ svn commit -m init\n> Adding branches\n> Adding trunk\n> \n> Committed revision 1.\n> $ svn switch $REPO/trunk\n> D trunk\n> D branches\n> Updated to revision 1.\n> \n> \n> # Create some content in trunk\n> # ----\n> $ echo 123 > testfile\n> $ svn add testfile\n> A testfile\n> $ svn commit -m test\n> Adding testfile\n> Transmitting file data .\n> Committed revision 2.\n> \n> \n> # Create a branch\n> # ----\n> $ svn cp $REPO/trunk $REPO/branches/b1 -m branch\n> \n> Committed revision 3.\n> \n> \n> # Produce some uncommitted changes on trunk\n> # ----\n> $ echo 456 > testfile\n> $ svn st\n> M testfile\n> $ svn diff\n> Index: testfile\n> ===================================================================\n> --- testfile (revision 2)\n> +++ testfile (working copy)\n> @@ -1 +1 @@\n> -123\n> +456\n> \n> \n> # Switch to the branch\n> # ----\n> $ svn switch $REPO/branches/b1\n> At revision 3.\n> $ svn st\n> M testfile\n> $ svn diff\n> Index: testfile\n> ===================================================================\n> --- testfile (revision 3)\n> +++ testfile (working copy)\n> @@ -1 +1 @@\n> -123\n> +456\n> \n> \n> The uncommitted changes survived the branch change and are still in the\n> working tree, in svn just like in git.\n> \n> Björn\n\nYes, 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?\n\nBTW, Is there a way to do 'svn checkout -b new_branch' into a new directory?\n"},{"id":"76615","messageId":"20080511132752.GA22778@atjola.homenet","threadId":"13474","inReplyTo":"4826EEDF.4010404@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-05-11T13:27:52Z","receivedAt":"2008-05-11T13:27:52Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.05.11 16:04:31 +0300, Dima Kagan wrote:\n> Björn Steinbrink wrote:\n> > On 2008.05.11 15:33:21 +0300, Dima Kagan wrote:\n> >>>> Basically I see that the same file I edited on the 'test_branch'\n> >>>> branch appears to be modified on the 'master' branch as well. This\n> >>>> behavior is unwanted, of course.\n> >>>>\n> >>>> Can someone please tell me, what am doing wrong? Or is this git's\n> >>>> normal behavior?\n> >> I just realized that this behavior is even more confusing. If I\n> >> commit the file on 'test_branch' and only then 'git checkout master'\n> >> the changes are not visible on 'master' until I merge. So why should\n> >> 'master' be affected by uncommitted changes on some branch???\n> > \n> > Uncommitted changes are not on any branch, they are in your working tree\n> >\n[example removed]\n> > \n> > \n> > The uncommitted changes survived the branch change and are still in the\n> > working tree, in svn just like in git.\n> \n> Yes, I am aware of that, except one rarely works in one directory on\n> multiple svn branches, because the branches are not private.\n\nI always did that, the working copy _is_ private even in svn, so messing\nwith that was not a problem there either.\n\n> Git's branches can be private, so perhaps this behavior should be\n> different from SVN?\n\nNo. Uncommitted changes are, well, uncommitted. They don't belong to any\nbranch yet. A branch is not some structure that contains history in\nitself. A branch just points to a commit, and the commits, with their\nparent-child relations, form the actual history. The index and working\ntree are not part of a branch.\n\nChanging that would even break a workflow that is rather common for me.\nI start working on something that is either just experimental or assumed\nto be a very small change. Then I realize that the change is worth\nkeeping and/or too big and deserves its own branch. At that point, I can\njust do \"git checkout -b new_branch\", and pretend that I started working\non that branch right from the start. With your proposed change, I would\nneed some extra command to transfer the work in progress from the old\nbranch to the new branch.\n\nIf I ever want to switch to another branch and not keep the changes in\nmy working tree and index, I stash them away or create a temporary\ncommit, which I later amend. That's a use-case that comes up rather\nseldom though (for me at least).\n\n> BTW, Is there a way to do 'svn checkout -b new_branch' into a new directory?\n\nThere's a script (new-working-tree or so) in contrib/ that can create a\nsecond working tree for a given repo, but I usually prefer to just clone\nmy repo locally. In the second repo, I can then switch branches as much\nas I like ;-)\n\nBjörn\n"},{"id":"76616","messageId":"4826F72D.2070205@gmail.com","threadId":"13474","inReplyTo":"20080511132752.GA22778@atjola.homenet","subject":"Re: Git branches - confusing behavior","fromName":"Dima Kagan","fromEmail":"dima.kagan@gmail.com","sentAt":"2008-05-11T13:39:57Z","receivedAt":"2008-05-11T13:39:57Z","isPatch":false,"sender":{"key":"dima.kagan@gmail.com","avatar":null},"body":"Björn Steinbrink wrote:\n > No. Uncommitted changes are, well, uncommitted. They don't belong to any\n> branch yet. A branch is not some structure that contains history in\n> itself. A branch just points to a commit, and the commits, with their\n> parent-child relations, form the actual history. The index and working\n> tree are not part of a branch.\n> \n> Changing that would even break a workflow that is rather common for me.\n> I start working on something that is either just experimental or assumed\n> to be a very small change. Then I realize that the change is worth\n> keeping and/or too big and deserves its own branch. At that point, I can\n> just do \"git checkout -b new_branch\", and pretend that I started working\n> on that branch right from the start. With your proposed change, I would\n> need some extra command to transfer the work in progress from the old\n> branch to the new branch.\n> \n> If I ever want to switch to another branch and not keep the changes in\n> my working tree and index, I stash them away or create a temporary\n> commit, which I later amend. That's a use-case that comes up rather\n> seldom though (for me at least).\n> \n> Björn\n\nMy 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.\n\nWhat do you think of that?\n"},{"id":"76617","messageId":"200805111540.05195.jnareb@gmail.com","threadId":"13474","inReplyTo":"4826DF6A.2070306@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-11T13:40:04Z","receivedAt":"2008-05-11T13:40:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dima Kagan wrote:\n> Jakub Narebski wrote:\n>> Dima Kagan writes:\n\n[...]\n> So if I am working on more than one branch at a time I need to commit\n> my changes every time before I do 'git checkout '?\n[...]\nNot necessary, see below (and it is not necessary bad).\n\n>>> Basically I see that the same file I edited on the 'test_branch'\n>>> branch appears to be modified on the 'master' branch as well. This\n>>> behavior is unwanted, of course.\n>>>\n>>> Can someone please tell me, what am doing wrong? Or is this git's\n>>> normal behavior?\n>> \n>> This is normal, and wanted, behavior.\n \n> That's a subjective point of view :) I'm coming from the SVN world and\n> uncommitted changes on one branch don't affect other branches. Is\n> there a way I can achieve this behavior with git? \n\nHow would you want git to behave, with \"git checkout \" changing \nbranches _in place_, in single working area? Besides, current \nbehavior, together with \"git checkout -m\" option, allows to change \nbranches when you have realized (after making some changes) that you \nare on wrong branch...\n\n\nThere are few possible solutions:\n\n1. Save state before switching branches\n\n1.1. You can simply commit changes before switching branch, perhaps with\n\"(WIP)\" (work in progress) in the commit message. Then, when you go \nback to the branch, you can continue your work, and simply --amend (as \nin \"git commit --amend\" a commit.\n\n1.2. You can use git-stash to save state of your working area (working \ndirectory) _and_ index, change branches, and when going back to branch \nrestore state using \"git stash apply\". I think you can save state even \nduring not resolved merge.\n\n1.3. If you use patch management interface on top of Git, like StGit\n(or Guilt), you can simply \"stg refresh\" a patch, then change branches. \nWhen returning to branch, use refresh and/or edit, then create new \npatch if you think current is finished (you can always go back...).\n\n\n2. Use separate working for differen branches: this is what Bazaar does, \nwhat Mercurial does by default without 'localbranch' extension, and I \nthink also what Subversion does. Take a look at contrib/workdir\non how to manage multiple working areas with single repository; the \ncore.workdir and --working-dir could also be of help.\n\nNote that in this case you have to take care to not have the same branch \nchecked out to two (or more) different working areas, to not stomp on \nyour changes, and to avoid confusion.\n\n\nFinal note: you would work better learning SCM \"the git way\", and not to \nrely on Subversion bad habits (yes, I know that bad CVS habits are \nworse...) ;-)\n\n-- \nJakub Narebski\nPoland\n"},{"id":"76618","messageId":"20080511140343.GA11248@mit.edu","threadId":"13474","inReplyTo":"4826EEDF.4010404@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-05-11T14:03:43Z","receivedAt":"2008-05-11T14:03:43Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, May 11, 2008 at 04:04:31PM +0300, Dima Kagan wrote:\n> > The uncommitted changes survived the branch change and are still in the\n> > working tree, in svn just like in git.\n> > \n> \n> Yes, I am aware of that, except one rarely works in one directory on\n> multiple svn branches, because the branches are not private. Git's\n> branches can be private, so perhaps this behavior should be\n> different from SVN?\n\nSo if you *want* to use separate working directories for different\nbranches, you can do that in git too. Some people find that more\nconvenient. Other people don't. \n\nKeep in mind, the other difference between git and svn is that until\ncommits are published, they can be freely altered. So many developers\nwho use git tend to commit their changes on the \"scratch branches\",\nand then if they need to modify them, use either \"git commit --amend\"\nor \"git commit --interactive\" as necessary to modify the commits on\nthe branches until they are just the way they want them.\n\nI will often have several different features \"in progress\" at\ndifferent times, and they are all on scratch branches. By keeping\nthem all on scratch branches, I can test them by creating a new\nscratch integration branch, and merge the various \"in progress\"\nfeatures together to see how they work together, then go back to the\nindividual feature branches to clean them up some more. \n\nWhen I'm satisified with a particular branch, I'll use \"git rebase\nmaster\" to rebase the work so that it is based off of the head of the\ndevelopment branch, and then do a fast forward merge to merge it into\nto development branch.\n\n> BTW, Is there a way to do 'svn checkout -b new_branch' into a new directory?\n\nNot as a single step operation, no. If you put the following in a\nscript, it will basically do what you want, though.\n\ncp -rl $old_repo $new_repo\ncd $new_repo\ngit checkout $new_branch\n\nIt does require that your editor save files by renaming the old file\nout of the way to file~ and then writing file as a new file, instead\nof opening the existing file and then doing an O_TRUNC (since that\nwill smash the file on the other repo), but as long as your editor is\nhard link friendly, this should work just fine, with minimal disk\nspace cost.\n\nOr you can just drop the hard link and just copy the whole repostory\nusing \"cp -r\" --- after all, svn is horribly wasteful of disk space,\nwith each repository taking twice the amount of space as the working\ndirectory, and so if you're used to paying that disk overhead cost\nwith SVN, then presumably you won't mind paying that price with git.\nThere are smarter ways of working, though, if you don't mind altering\nyour work flow a little.\n\n \t \t\t \t \t - Ted\n"},{"id":"76620","messageId":"6b6419750805110825t51730d16y211d2c502a1b302d@mail.gmail.com","threadId":"13474","inReplyTo":"4826F72D.2070205-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org","subject":"Re: Git branches - confusing behavior","fromName":"Patrick Aljord","fromEmail":"patcito-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2008-05-11T15:25:04Z","receivedAt":"2008-05-11T15:25:04Z","isPatch":false,"sender":{"key":"patcito-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"\nOn Sun, May 11, 2008 at 8:39 AM, Dima Kagan wrote:\n> 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.\n>\n> What do you think of that?\n\nyou can do just that with an alias, in .git/config add:\n\n[alias]\n auto-stash = !git stash && git checkout $1\n\nthen type \"git auto-stash master\" or \"git auto-stash some_branch\" and\nit should stash and checkout the branch.\n\nCheers,\n\nPat\n\n--~--~---------~--~----~------------~-------~--~----~\nYou received this message because you are subscribed to the Google Groups \"Git for human beings\" group.\nTo post to this group, send email to git-users-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org\nTo unsubscribe from this group, send email to git-users-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org\nFor more options, visit this group at http://groups.google.com/group/git-users?hl=en\n-~----------~----~----~----~------~----~------~--~---\n"},{"id":"76622","messageId":"20080511153954.GA8129@mithlond.arda.local","threadId":"13474","inReplyTo":"4826F72D.2070205@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-05-11T15:39:54Z","receivedAt":"2008-05-11T15:39:54Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Dima Kagan wrote (2008-05-11 16:39 +0300):\n\n> My proposed change shouldn't necessarily break the described workflow.\n> Git can keep the current behavior for new branches, but automatically\n> 'stash' the changes when checking-out an existing branch. At least\n> having an optional parameter for \"auto-stashing\" will be nice.\n> \n> What do you think of that?\n\nWith the fact that Git's branches are just pointers to a commit (and\ntherefore to a history) and that you can checkout anything that refers\nto a commit (branches, tags, SHA1's, relative pointers like\nHEAD@{30.minutes.ago}^2~3) I think such auto-stashing would be make\nthings pretty complicated and unintuitive in the big picture. The user\ninterface remains simpler if we just learn to use \"git stash\" to\ntemporarily put away changes in the index and the working directory when\nwe need to.\n"},{"id":"76682","messageId":"buohcd4ufl0.fsf@dhapc248.dev.necel.com","threadId":"13474","inReplyTo":"4826F72D.2070205@gmail.com","subject":"Re: Git branches - confusing behavior","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-05-12T07:49:47Z","receivedAt":"2008-05-12T07:49:47Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Dima Kagan writes:\n> My proposed change shouldn't necessarily break the described\n> workflow. Git can keep the current behavior for new branches, but\n> automatically 'stash' the changes when checking-out an existing\n> branch.\n\nIt's not going to happen, at least by default. Many people already rely\non -- and like -- the current behavior, which is often quite convenient\n(edit some files and then realize \"oh, I should commit these to another\nbranch\"... no prob! :-).\n\nOccasionally it is inconvenient, of course, but git offers mechanisms to\nuse in such cases, most notably \"git stash\" (and of course super-cheap\nlocal branches which can be amended or even deleted later).\n\nI think the real problem here is that you haven't quite gotten used\nto git yet.\n\n-Miles\n\n-- \nFaith, n. Belief without evidence in what is told by one who speaks without\nknowledge, of things without parallel.\n"}]}