{"thread":{"id":"11897","subject":"[Bug?] uncommited changes cross branches","startedAt":"2008-02-05T14:45:30Z","lastAt":"2008-02-05T20:34:09Z","messageCount":3,"participants":["Rhodes, Kate","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"67519","messageId":"CB070331-8CA6-42CD-9CAD-20371F16DCD8@gmail.com","threadId":"11897","inReplyTo":null,"subject":"[Bug?] uncommited changes cross branches","fromName":"Rhodes, Kate","fromEmail":"masukomi@gmail.com","sentAt":"2008-02-05T14:45:30Z","receivedAt":"2008-02-05T14:45:30Z","isPatch":false,"sender":{"key":"masukomi@gmail.com","avatar":null},"body":"If you have a file that exists in two branches in the same repo, make  \na change to it without committing, then switch branches the changes  \ncarry over, but if you make changes to a file that exists in only one  \nof the repos and try and switch branches Git complains that the file  \nisn't uptodate.  The latter behavior seems correct to me.\n\nChanges I make in any branch should not just follow me around as I  \nswitch through other branches. It seems not only conceptually broken  \nto me, but also something that make it very easy to accidentally  \ncommit changes to an unintended branch if you weren't paying close  \nattention when you switched. I think that the appropriate action is to  \nnot allow a user to switch branches whenever there are files that  \naren't up to date (committing, git-stash, and checkout -m  being the  \nobvious, and safe, ways around the blockage).\n\nThe documentation *seems* to agree with me and it looks like it was  \nthe intent of the code to prevent this too, but it obviously doesn't.\n\n\nIn case my description was a little confusing below is a real world  \nexample of what I'm talking about. The last command is what I believe  \nshould not be possible:\n\n$ temp krhodes$ mkdir foo\n$ temp krhodes$ cd foo/\n$ foo krhodes$ git --version\ngit version 1.5.4.2.g41ac4\n$ foo krhodes$ git init\nInitialized empty Git repository in .git/\n$ foo krhodes$ echo \"foo\" > foo.txt\n$ foo krhodes$ git add foo.txt\n$ foo krhodes$ git commit -a -m \" initial commit\"\nCreated initial commit 10d7a21:  initial commit\n  1 files changed, 1 insertions(+), 0 deletions(-)\n  create mode 100644 foo.txt\n$ foo krhodes$ git checkout -b branch_one\nSwitched to a new branch \"branch_one\"\n$ foo krhodes$ echo \"bar\" > bar.txt\n$ foo krhodes$ git add bar.txt\n$ foo krhodes$ git commit -a -m \"initial branch_one_commit\"\nCreated commit 3251c16: initial branch_one_commit\n  1 files changed, 1 insertions(+), 0 deletions(-)\n  create mode 100644 bar.txt\n$ foo krhodes$ echo \"baz\" > bar.txt\n$ foo krhodes$ git checkout master\nfatal: Entry 'bar.txt' not uptodate. Cannot merge.\n$ foo krhodes$ git checkout bar.txt\n$ foo krhodes$ git checkout master\nSwitched to branch \"master\"\n$ foo krhodes$ echo \"baz\" > foo.txt\n$ foo krhodes$ git checkout branch_one\nM\tfoo.txt\nSwitched to branch \"branch_one\"\n\n-------\n-masukomi\n"},{"id":"67523","messageId":"alpine.LSU.1.00.0802051502360.8543@racer.site","threadId":"11897","inReplyTo":"CB070331-8CA6-42CD-9CAD-20371F16DCD8@gmail.com","subject":"Re: [Bug?] uncommited changes cross branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-05T15:07:12Z","receivedAt":"2008-02-05T15:07:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 5 Feb 2008, Rhodes, Kate wrote:\n\n> If you have a file that exists in two branches in the same repo, make a \n> change to it without committing, then switch branches the changes carry \n> over, but if you make changes to a file that exists in only one of the \n> repos and try and switch branches Git complains that the file isn't \n> uptodate.  The latter behavior seems correct to me.\n\nIt is slightly different: if you change a file without committing _-and- \nthe switch to another branch does not touch the file, git does not \ncomplain.\n\nThe rationale: git should refuse to switch branches _only_ if uncommitted \nchanges would be lost.\n\nHowever, if you change a file whose content is different in the other \nbranch (and \"not existing\" qualifies), the uncommitted changes would be \nlost, and git should complain.\n\nCiao,\nDscho\n"},{"id":"67546","messageId":"140813C2-123F-48CB-99CC-4E9A9B6C33B9@gmail.com","threadId":"11897","inReplyTo":"alpine.LSU.1.00.0802051502360.8543@racer.site","subject":"Re: [Bug?] uncommited changes cross branches","fromName":"Rhodes, Kate","fromEmail":"masukomi@gmail.com","sentAt":"2008-02-05T20:34:09Z","receivedAt":"2008-02-05T20:34:09Z","isPatch":false,"sender":{"key":"masukomi@gmail.com","avatar":null},"body":"\nOn Feb 5, 2008, at 10:07 AM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Tue, 5 Feb 2008, Rhodes, Kate wrote:\n>\n>> If you have a file that exists in two branches in the same repo,  \n>> make a\n>> change to it without committing, then switch branches the changes  \n>> carry\n>> over, but if you make changes to a file that exists in only one of  \n>> the\n>> repos and try and switch branches Git complains that the file isn't\n>> uptodate.  The latter behavior seems correct to me.\n>\n> It is slightly different: if you change a file without committing _- \n> and-\n> the switch to another branch does not touch the file, git does not\n> complain.\n>\n> The rationale: git should refuse to switch branches _only_ if  \n> uncommitted\n> changes would be lost.\n>\n> However, if you change a file whose content is different in the other\n> branch (and \"not existing\" qualifies), the uncommitted changes would  \n> be\n> lost, and git should complain.\n\nThat makes sense, but I wonder if the distinction isn't a little too  \nsubtle for most users to pick up on without being told, and if letting  \nuncommitted changes cross branches without some explicit user approval  \nis a good idea. I assume that once someone becomes really used to  \nworking with multiple branches within the same repo you'd build up  \nsubconscious safeguards against accidentally pulling changes into a  \nbranch you didn't mean to, but I worry that it's going to be  \nproblematic for users starting out with git.\n\nTo me it's like the difference between -d and -D in git-branch. It's  \ngenerally a good idea to use -d by default and have git warn you that  \nyou're about to do something that could screw you up.\n\n-kate == masukomi\n"}]}