{"thread":{"id":"3070","subject":"My first git success","startedAt":"2006-01-13T14:51:24Z","lastAt":"2006-01-15T10:44:54Z","messageCount":15,"participants":["walt","Linus Torvalds","Randal L. Schwartz","Peter Eriksen","Junio C Hamano","sean"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14614","messageId":"dq8epd$k28$1@sea.gmane.org","threadId":"3070","inReplyTo":null,"subject":"My first git success","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2006-01-13T14:51:24Z","receivedAt":"2006-01-13T14:51:24Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"All the help you guys have given me lately has at least\nfixed one kernel bug :o)\n\nAfter using git-bisect to find the responsible commit,\nI emailed the maintainer who sent me back a patch to try.\n\nI used git-checkout to make a new test branch, applied\nand tested the patch (which fixed the bug) and I just\nsent off an email to the maintainer to confirm.\n\nAnd it was all so easy I never broke a sweat.  Amazing!\n\nSo thank you all again for the help and your great work.\n"},{"id":"14616","messageId":"Pine.LNX.4.64.0601130909290.3535@g5.osdl.org","threadId":"3070","inReplyTo":"dq8epd$k28$1@sea.gmane.org","subject":"Re: My first git success","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-13T17:11:19Z","receivedAt":"2006-01-13T17:11:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 13 Jan 2006, walt wrote:\n> \n> And it was all so easy I never broke a sweat.  Amazing!\n\nHeh. You're the \"good tester\" kind of person. Most people don't bother to \nexplain their problems well, and don't even bother to listen. And they \nnever call it \"easy\" if they had to get explanations.\n\nI still hope the exchanges will result in more docs, or at least other \nlurkers on the list also learning a new trick or two..\n\n\t\t\tLinus\n"},{"id":"14622","messageId":"86y81kvtvj.fsf@blue.stonehenge.com","threadId":"3070","inReplyTo":"Pine.LNX.4.64.0601130909290.3535@g5.osdl.org","subject":"Re: My first git success","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-01-13T18:57:04Z","receivedAt":"2006-01-13T18:57:04Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds <torvalds@osdl.org> writes:\n\nLinus> I still hope the exchanges will result in more docs, or at least other \nLinus> lurkers on the list also learning a new trick or two..\n\nI've also enjoyed a bit of success putting a website under git.  I started\nworking on AJAX-ing some of the code, but I needed to do maintainence on the\nlive site, so I've just simply done \"git-checkout master\" to work on that, and\n\"git-checkout ajax; git-pull . master\" when I want to continue work on the\najax upgrades.\n\nHowever, before I bug-fix, I have to \"snapshot\" any working changes in the\najax branch or I would lose them on \"git-checkout master\", which gives me\ncommits that look like \"snapshot\".  Am I doing that wrong?  Is there a better\nway to do parallel development of a \"live vs upgrade\" branch, and make commits\nonly when I make progress?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"14625","messageId":"7vmzhz7wcm.fsf@assigned-by-dhcp.cox.net","threadId":"3070","inReplyTo":"86y81kvtvj.fsf@blue.stonehenge.com","subject":"Re: My first git success","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-13T19:37:29Z","receivedAt":"2006-01-13T19:37:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> However, before I bug-fix, I have to \"snapshot\" any working changes in the\n> ajax branch or I would lose them on \"git-checkout master\", which gives me\n> commits that look like \"snapshot\".  Am I doing that wrong?  Is there a better\n> way to do parallel development of a \"live vs upgrade\" branch, and make commits\n> only when I make progress?\n\nAlthough I am sure others would suggest to use more than one\nworking tree, here are what I generally do, which does not\nrequire more than one.\n\n-- >8 --\n\nInterrupted workflow\n--------------------\n\nWhen you are in the middle of a large change, you can get\ninterrupted.  The files in your working tree is not in any shape\nto be committed, but you need to get to the other branch for a\nquick fix.\n\n------------\n: on ajax; work work work\n: on ajax; git commit -a -m 'snapshot WIP' <1>\n: on ajax; git checkout master\n: on master; fix fix fix\n: on master; git commit ;# commit with real log\n: on master; git checkout ajax\n: on ajax; git reset --soft HEAD^ ;# go back to WIP state <2>\n\n<1> This commit will get blown away so short log message is just fine.\n<2> This removes the 'WIP' commit from the commit history, and makes\n    your working tree in the state just before you made that snapshot.\n\n------------\n\nThe only difference between the state immediately before <1> and\nimmediately after <2> is that files you committed in <1> are\nstill registered in index at state <2>, so your \"git diff\" would\nnot give you what you were in the middle of doing at point <2>\nand you need to say \"git diff HEAD\" instead.  You could do a\n\n------------\n: on ajax; git read-tree -m HEAD\n------------\n\nimmediately after the soft reset, which sets your index file to\nthe last commit you were basing your ajax work on.\n"},{"id":"14624","messageId":"20060113201421.GA25252@ebar091.ebar.dtu.dk","threadId":"3070","inReplyTo":"86y81kvtvj.fsf@blue.stonehenge.com","subject":"Re: My first git success","fromName":"Peter Eriksen","fromEmail":"s022018@student.dtu.dk","sentAt":"2006-01-13T20:14:21Z","receivedAt":"2006-01-13T20:14:21Z","isPatch":false,"sender":{"key":"s022018@student.dtu.dk","avatar":null},"body":"On Fri, Jan 13, 2006 at 10:57:04AM -0800, Randal L. Schwartz wrote:\n> >>>>> \"Linus\" == Linus Torvalds <torvalds@osdl.org> writes:\n> \n> Linus> I still hope the exchanges will result in more docs, or at least other \n> Linus> lurkers on the list also learning a new trick or two..\n> \n> I've also enjoyed a bit of success putting a website under git.  I started\n> working on AJAX-ing some of the code, but I needed to do maintainence on the\n> live site, so I've just simply done \"git-checkout master\" to work on that, and\n> \"git-checkout ajax; git-pull . master\" when I want to continue work on the\n> ajax upgrades.\n> \n> However, before I bug-fix, I have to \"snapshot\" any working changes in the\n> ajax branch or I would lose them on \"git-checkout master\", which gives me\n> commits that look like \"snapshot\".  Am I doing that wrong?  Is there a better\n> way to do parallel development of a \"live vs upgrade\" branch, and make commits\n> only when I make progress?\n\nI've been wondering this myself.  Perhaps the following way would work?\n\n    git checkout ajax          # Work on the ajax branch.\n    git diff HEAD >ajaxdiff\n    git checkout -f master     # Work on the bug fix in master.\n    git commit -a -m \"Bug fix in master\"\n    git checkout ajax\n    git apply ajaxdiff\n    git commit -a -m \"Finished commit in ajax\"\n\nThis is untested, so it's only for inspiration.\n\nRegards,\n\nPeter\n"},{"id":"14652","messageId":"dqb5vg$a09$1@sea.gmane.org","threadId":"3070","inReplyTo":"Pine.LNX.4.64.0601130909290.3535@g5.osdl.org","subject":"Re: My first git success [not quite]","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2006-01-14T15:39:28Z","receivedAt":"2006-01-14T15:39:28Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Fri, 13 Jan 2006, walt wrote:\n>> And it was all so easy I never broke a sweat.  Amazing!\n\n>  ...Most people don't bother to \n> explain their problems well...\n\nI see I still have a problem:  my mental model of how git\nworks is still wrong.\n\nI used 'git-checkout -b test' to create a disposable place\nto test the patch I was given.\n\nOkay, making sure I'm now sitting in 'test', I apply the\npatch to foo.c and do my testing.\n\nNow, intending to delete my 'test' branch, I do git-checkout\nmaster.  My mental model predicts that 'master' should still\nbe identical to 'origin' because I did the patching in 'test'.\nAm I right so far?\n\nThe problem I see is that, after switching back to 'master',\nfoo.c is the patched version, not your original version.  I\nfigured that the git-checkout would overwrite any changes I\nmade to foo.c, but that doesn't seem to be the case.  To get\nyour original version back I had to delete foo.c and do a\ngit-checkout foo.c (or git-checkout -f master).\n\nSo, I clearly don't understand what git-checkout does.  It\ndoesn't seem to touch the already-checked-out sources at\nall, which is what I would expect it to do.\n\nCan someone hit me with the clue-stick here?  Thanks!\n"},{"id":"14653","messageId":"BAYC1-PASMTP10B423DC1B2FC1F8C9992BAE190@CEZ.ICE","threadId":"3070","inReplyTo":"dqb5vg$a09$1@sea.gmane.org","subject":"Re: My first git success [not quite]","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-01-14T15:55:04Z","receivedAt":"2006-01-14T15:55:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 14 Jan 2006 07:39:28 -0800\nwalt <wa1ter@myrealbox.com> wrote:\n\n> Linus Torvalds wrote:\n> > \n> > On Fri, 13 Jan 2006, walt wrote:\n> >> And it was all so easy I never broke a sweat.  Amazing!\n> \n> >  ...Most people don't bother to \n> > explain their problems well...\n> \n> I see I still have a problem:  my mental model of how git\n> works is still wrong.\n> \n> I used 'git-checkout -b test' to create a disposable place\n> to test the patch I was given.\n> \n> Okay, making sure I'm now sitting in 'test', I apply the\n> patch to foo.c and do my testing.\n> \n> Now, intending to delete my 'test' branch, I do git-checkout\n> master.  My mental model predicts that 'master' should still\n> be identical to 'origin' because I did the patching in 'test'.\n> Am I right so far?\n> \n> The problem I see is that, after switching back to 'master',\n> foo.c is the patched version, not your original version.  I\n> figured that the git-checkout would overwrite any changes I\n> made to foo.c, but that doesn't seem to be the case.  To get\n> your original version back I had to delete foo.c and do a\n> git-checkout foo.c (or git-checkout -f master).\n> \n> So, I clearly don't understand what git-checkout does.  It\n> doesn't seem to touch the already-checked-out sources at\n> all, which is what I would expect it to do.\n> \n> Can someone hit me with the clue-stick here?  Thanks!\n> \n\nHi Walt,\n\nWhen you switch branches _uncommitted_ changes will stay in\nyour working directory.   This lets you change to a different\nbranch before committing something you're working on for\ninstance.   So likely, even though you had switched to your\ntest branch to apply the patch, you didn't actually commit\nit into that branch before switching back to master.\n\nHere's a little example that should show the difference:\n\n\nCreate a test repo:\n\t$ mkdir walt ; cd walt\n\t$ git-init-db\n\tdefaulting to local storage area\n\nCreate a simple file and commit it on the master branch:\n\t$ echo A > file\n\t$ git add file\n\t$ git commit -m \"initial\"\n\tCommitting initial tree a9e3325a07117aa5381e044a8d96c26eb30d729d\n\nCreate and checkout a new branch named \"test\":\n\t$ git checkout -b test\n\t$ git branch\n\t  master\n\t* test\n\nModify (ie. patch) the file:\n\t$ echo B > file\n\t$ cat file\n\tB\n\nNow, if you switch back to the master branch, the file is still patched:\n\t$ git checkout master\n\t$ cat file\n\tB\n\nSwitch back to the test branch and commit the change this time:\n\t$ git checkout test\n\t$ git commit -m \"test branch\" file\n\t$ cat file\n\tB\n\nNow, this time when you switch back to master, you'll get what you expect:\n\t$ git checkout master\n\t$ cat file\n\tA\n\n\nHTH,\nSean\n"},{"id":"14655","messageId":"dqbbo9$s49$1@sea.gmane.org","threadId":"3070","inReplyTo":"BAYC1-PASMTP10B423DC1B2FC1F8C9992BAE190@CEZ.ICE","subject":"Re: My first git success [not quite]","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2006-01-14T17:18:01Z","receivedAt":"2006-01-14T17:18:01Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"sean wrote:\n> > On Sat, 14 Jan 2006 07:39:28 -0800\n> > walt <wa1ter@myrealbox.com> wrote:\n[...]\n>> >> So, I clearly don't understand what git-checkout does.  It\n>> >> doesn't seem to touch the already-checked-out sources at\n>> >> all, which is what I would expect it to do.\n\n> > Hi Walt,\n> >\n> > When you switch branches _uncommitted_ changes will stay in\n> > your working directory.   This lets you change to a different\n> > branch before committing something you're working on for\n> > instance.\n\nAh!  The underlying reason is what I was missing.\n\n> >   So likely, even though you had switched to your\n> > test branch to apply the patch, you didn't actually commit\n> > it into that branch before switching back to master.\n\nRight.  And *my* reasoning (FWIW) is that I was intending\nto throw the entire branch away so I didn't see any need to\ncommit.  (But men always have that problem ;o)\n\nI suppose the underlying problem is that I don't think like\na developer.  My wish for a future improvement for git would\nbe a bonehead<-->expert switch that would turn on some basic\nwarning messages.  In this particular example, I would have\nwelcomed a warning message that said:  \"You have uncommitted\nchanges!  Hit 'D' to discard them or <Enter> to keep them without\ncommitting\".  An experienced git user would want to turn that off,\nmost likely.\n\nThanks for the clue-stick, and I very much appreciate your\npatience.\n"},{"id":"14656","messageId":"86acdyu2dz.fsf@blue.stonehenge.com","threadId":"3070","inReplyTo":"dqbbo9$s49$1@sea.gmane.org","subject":"Re: My first git success [not quite]","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-01-14T17:48:24Z","receivedAt":"2006-01-14T17:48:24Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"walt\" == walt  <wa1ter@myrealbox.com> writes:\n\nwalt> I suppose the underlying problem is that I don't think like\nwalt> a developer.\n\nWell, I'm a developer and *I* also had that problem while working\non my \"ajax\" branch.\n\nMaybe git-checkout should by default *warn* when it is leaving\nthings in the tree that are indexed but not updated in the index\n(committed?).  And you'd have to add a --no-warn thingy to turn\nthat off.  Then beginners wouldn't be quite as confused.  I'm not\ntalking about things that are .gitignore'd... just things like\nwalt's example.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"14660","messageId":"Pine.LNX.4.64.0601141117120.13339@g5.osdl.org","threadId":"3070","inReplyTo":"dqb5vg$a09$1@sea.gmane.org","subject":"Re: My first git success [not quite]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-14T19:25:54Z","receivedAt":"2006-01-14T19:25:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 14 Jan 2006, walt wrote:\n> \n> I see I still have a problem:  my mental model of how git\n> works is still wrong.\n> \n> I used 'git-checkout -b test' to create a disposable place\n> to test the patch I was given.\n> \n> Okay, making sure I'm now sitting in 'test', I apply the\n> patch to foo.c and do my testing.\n> \n> Now, intending to delete my 'test' branch, I do git-checkout\n> master.  My mental model predicts that 'master' should still\n> be identical to 'origin' because I did the patching in 'test'.\n> Am I right so far?\n\nYes.\n\n> The problem I see is that, after switching back to 'master',\n> foo.c is the patched version, not your original version.\n\nAhh. This is very much done on purpose.\n\nSomething that hasn't been committed (it is \"dirty\" in git terms) is \nreally not associated with any branch _at_all_. It's purely associated \nwith the checked-out directory.\n\nNow, what happens is that when you change branches with a dirty tree, the \n\"git checkout\" will do one of two things:\n\n - if the dirty files are _identical_ in both branches, the dirty state \n   (remember: it's not associated with any particular branch) will follow \n   the branch switch.\n\n   This is very convenient. You've edited a file, but you realized that \n   you did this in the wrong branch. For example, you realize that you are \n   in the main development branch, but that your edit is pretty damn \n   experimental. So what you do is _not_ to undo your edit, but to create \n   a new branch and switch to it, and then commit it _there_.\n\n\t\tgit checkout -b experimental\n\t\tgit commit --all\n\n   (you might have an old experimental branch too, in which case you don't \n   need to create it, but then you can only switch to it if the file you \n   edited is the same as in your development branch)\n\n - otherwise, the switch will fail, and you'll have to either commit the \n   changes in that branch, or you'll have to undo them.\n\nNow, Junio has patches (maybe they even got merged in mainline) to relax \nthe \"exactly the same\" rule a bit, and instead try to merge any dirty \nstate into the branch you're switching to. Conceptually nothing changed: \ndirty state is branchless, so when you switch to another branch, the dirty \nstate follows you. \n\n> I figured that the git-checkout would overwrite any changes I\n> made to foo.c, but that doesn't seem to be the case.  To get\n> your original version back I had to delete foo.c and do a\n> git-checkout foo.c (or git-checkout -f master).\n\nYes. You can either undo the dirty state, or you can do a \"forced \ncheckout\" that will start from scratch. And the dirty state will be _gone_ \nin both cases. It won't be saved away in the \"original branch\". Again, \nthis is 100% consistent with the notion that dirty state is branchless. \nOnly _committed_ state is committed to a particular branch.\n\n> So, I clearly don't understand what git-checkout does.  It\n> doesn't seem to touch the already-checked-out sources at\n> all, which is what I would expect it to do.\n\nNo, you understand exactly what git-checkout does, you just didn't realize \nthat dirty state was different from committed state.\n\n\t\tLinus\n"},{"id":"14666","messageId":"7vzmlyft61.fsf@assigned-by-dhcp.cox.net","threadId":"3070","inReplyTo":"86acdyu2dz.fsf@blue.stonehenge.com","subject":"Re: My first git success [not quite]","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-14T20:31:18Z","receivedAt":"2006-01-14T20:31:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Well, I'm a developer and *I* also had that problem while working\n> on my \"ajax\" branch.\n>\n> Maybe git-checkout should by default *warn* when it is leaving\n> things in the tree that are indexed but not updated in the index...\n\nWhat Linus already said.  But you may find this on top of the\ncurrent \"master\" branch useful.\n\nLikes, dislikes?\n\n-- >8 --\n[PATCH] checkout: show dirty state upon switching branches.\n\nThis shows your working file state when you switch branches.  As\na side effect, \"git checkout\" without any branch name (i.e. stay\non the current branch) becomes a more concise shorthand for the\n\"git status\" command.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex bd7f007..d99688f 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -164,6 +164,9 @@ else\n \tesac\n \texit 0\n     )\n+    saved_err=$?\n+    git diff-files --name-status\n+    (exit $saved_err)\n fi\n \n # \n"},{"id":"14670","messageId":"dqbnl1$3si$1@sea.gmane.org","threadId":"3070","inReplyTo":"Pine.LNX.4.64.0601141117120.13339@g5.osdl.org","subject":"Re: My first git success [not quite]","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2006-01-14T20:41:04Z","receivedAt":"2006-01-14T20:41:04Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"Linus Torvalds wrote:\n[...]\n> Now, what happens is that when you change branches with a dirty tree, the \n> \"git checkout\" will do one of two things:\n> \n>  - if the dirty files are _identical_ in both branches...\n\nI'm sorry to be quibbling over semantics, truly I am!  But here\nis my confusion:  if modified-but-uncommitted (hence dirty) files\nare not associated with *any* branch, then how could 'dirty' files\nbe 'in' both branches (or 'in' any branch at all)?\n\nThanks for your continued patience with me!  I hate to distract you\nfrom your real work -- I can only hope that others are learning as\nmuch from your answers as I am.\n"},{"id":"14671","messageId":"7vbqyefsbc.fsf@assigned-by-dhcp.cox.net","threadId":"3070","inReplyTo":"dqbnl1$3si$1@sea.gmane.org","subject":"Re: My first git success [not quite]","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-14T20:49:43Z","receivedAt":"2006-01-14T20:49:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"walt <wa1ter@myrealbox.com> writes:\n\n> Linus Torvalds wrote:\n> [...]\n>> Now, what happens is that when you change branches with a dirty tree, the \n>> \"git checkout\" will do one of two things:\n>> \n>>  - if the dirty files are _identical_ in both branches...\n>\n> I'm sorry to be quibbling over semantics, truly I am!  But here\n> is my confusion:  if modified-but-uncommitted (hence dirty) files\n> are not associated with *any* branch, then how could 'dirty' files\n> be 'in' both branches (or 'in' any branch at all)?\n\n\"If the paths that you have dirty are the same in both\nbranches\".\n\nThat is:\n\n* \"master\" branch has Makefile file, as taken from git.git\n\n* \"my-work\" branch was made out of \"master\" branch, but\n  has not modified Makefile file.\n\n\tgit-diff-tree master my-work Makefile\n\n  would yield nothing.\n\n* You are on \"master\" branch.  You have added a new target to\n  your Makefile in the working tree and the path is dirty.\n\nThen:\n\n\tgit checkout my-work\n\nwould notice that the path \"Makefile\" are identical between two\nbranches \"master\" you are switching from and \"my-work\" you are\nswitching to.  The \"Makefile\" in your working tree does not\nmatch either tree, but that difference is carried over while\nswitching branches.\n\nAs Linus mentioned, with '-m' flag to \"git checkout\", it can\nmerge your local modifications even when \"master\" and \"my-work\"\ndisagrees on \"Makefile\" in this example.\n\n        \n"},{"id":"14673","messageId":"Pine.LNX.4.64.0601141350590.13339@g5.osdl.org","threadId":"3070","inReplyTo":"dqbnl1$3si$1@sea.gmane.org","subject":"Re: My first git success [not quite]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-14T21:57:07Z","receivedAt":"2006-01-14T21:57:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 14 Jan 2006, walt wrote:\n>\n> Linus Torvalds wrote:\n> [...]\n> > Now, what happens is that when you change branches with a dirty tree, the \n> > \"git checkout\" will do one of two things:\n> > \n> >  - if the dirty files are _identical_ in both branches...\n> \n> I'm sorry to be quibbling over semantics, truly I am!  But here\n> is my confusion:  if modified-but-uncommitted (hence dirty) files\n> are not associated with *any* branch, then how could 'dirty' files\n> be 'in' both branches (or 'in' any branch at all)?\n\nThe file itself is associated with the branch. It's just that the _dirty_ \npart isn't.\n\nOf course, you can also truly have files that aren't associated with \neither branch at all: files that haven't gotten committed at all. They're \nalso \"dirty state\", and exactly like modifications to known files, they \nare carried along with the switch, so they'll exist in the directory tree \nafter a \"git checkout\".\n\nAnyway, in git, a \"branch\" is technically really nothing more than \"top of \na commit chain\". If you look into the files that describe a branch, you'll \nliterally just find the name of the top commit. Do a\n\n\tcat .git/refs/heads/master\n\nto see. \n\nSo anything that isn't described by that commit is by definition \"dirty \nstate\", whether it's because you've edited something (but not checked it \nin) or because there's some random generated file in the working tree.\n\nSo when you switch branches, you really should think of it as \"ok, the \ncommitted state was switched around\", and everything else was just \"moved \nalong\".\n\n\t\tLinus\n"},{"id":"14682","messageId":"7v4q457ot5.fsf@assigned-by-dhcp.cox.net","threadId":"3070","inReplyTo":"Pine.LNX.4.64.0601141117120.13339@g5.osdl.org","subject":"Re: My first git success [not quite]","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-15T10:44:54Z","receivedAt":"2006-01-15T10:44:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Now, Junio has patches (maybe they even got merged in mainline) to relax \n> the \"exactly the same\" rule a bit, and instead try to merge any dirty \n> state into the branch you're switching to. Conceptually nothing changed: \n> dirty state is branchless, so when you switch to another branch, the dirty \n> state follows you. \n\nFYI, I pushed this out, along with some other changes.\n\n * checkout -m can be used to merge while switching branches.\n * format-patch now always does --mbox and shows RFC2822 Date.\n * clone --naked can be used for creating \"project.git\" style repository.\n * octopus allows hand resolving in limited form.\n * show-branch user interface updates.\n * push --tags to push all tags; it does not fall back on \"matching\" refs.\n"}]}