James Byrne wrote: > I have been using Git for about a year now, but always in the master > branch. I decided to try working in a branch to get experience with > merging. Naturally enough, I am now observing some behaviour that I do > not understand. I would appreciate any explanation of what is happening > and whether this is expected behaviour or not. > > I initially pull from the remote repository and then checkout -b > workcopy from the master. At this point workcopy and master are > identical. In workcopy I modify x.rb and y.rb. I then add/commit x.rb > in workcopy. Next I checkout back to master.
But you didn't commit y.rb so the modifications still exist in your work copy. (not your branch named workcopy, which would be very confusing to me to name a branch that. I'd name it something like experimental or after whatever feature I was working on). > From what i had read about git I believed that all the modifications > that I made to x and y in workcopy only affectedi workcopy; and that > those files in the master branch were still pristine as when they had > been pulled. However, when I checkouted the master branch this is what > I saw: You misinterpreted what you read. The changes you make in a working copy affect the working copy (i.e. the files you see when listing your project files). > > $ git co master > M y.rb > Switched to branch master > $ > $ git status > # On branch master > # Changed but not updated: > # (use "git add <file>..." to update what will be committed) > # > # modified: y.rb > no changes added to commit (use "git add" and/or "git commit -a") > $ Of course y.rb in your working copy shows the modification because you modified it. You didn't commit it to your branch so git checkout of master merges your working copy changes to what it gets from the master branch effectively patching master's version of the file with your working copy changes. This is expected and good behavior. You wouldn't want git stomping on you local uncommitted changes. I you have changes in your working copy when working on a branch and do not want to commit those changes permanently, you can "stash" the changes before checking out master. You do this using git stash command. Typically, however, it makes sense to commit all your changes to the branch before switch to another. After all, if it's an experimental branch and you're at a reasonable time to switch away to something else it's okay to just commit everything whether it's fully working or not. It is an "experimental" branch after all. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
