On Wed, 17 Sep 2014 05:52:29 -0700 (PDT) Dmitry Moscow <koktebelnig...@gmail.com> wrote:
> I come from an SVN background, and I have a hard time grasping Git's > philosophy. In particular, I'm confused by the following. > > 1. > > Imagine I have made some changes in my working dir. If I switch to > another branch, the changes*remain*, which is very unusual, from > an SVN point of view. This means that uncommitted changes are*shared* > between the branches. Moreover, the "stage property" of the files is > also *shared* between the branches: if I call git add * in one > branch, then all the files will be added to next commit in all the > branches. Looks like my branches differ only by already *committed* > files. > So, if uncommitted data are *shared*, then, no matter which branch > I am on now, I will commit *all the staged files*, even if they were > added in different branches! As I come from an SVN background, this > strikes me as very odd. > > Am I correct, or am I just confused? Why does Git work in this way? > 2. > > Sometimes, Git tells me something like this: > > Cannot switch to another branch because your changes will be > erased. Commit them first. > > In SVN, that's not a problem: branches are *independent*. Why and > when does this happen in Git? With regard to the behaviour you describe Git is not different from Subversion: changes made to the checkout (Git calls it "work tree", Subversion calls it working directory, IIRC) do not belong to any tree in both of these systems, instead, they are *based* on a specific state of the project -- the one being checked out at the time the changes were made. If this will help you to build a correct mental model, `git branch foo` behaves much like Subversion's `svn switch ^/branches/foo`. Again, whatever uncommitted changes you have in your checkout are not on any branch until they're actually committed. If you want to persist them while switching branches in Git, there are three approaches: * The stash. This is a special area which might keep uncommitted changes and apply them back. Read up any book on Git to get more info. * Make a temporary commit, then switch the branch. No, really, this is not Subversion, so it's perfercly OK to create an ugly, work-in-progress commit and then later either refine it through `git commit --amend` or throw it away completely and replace with another one or even a series of commits. Again, any book on Git will get you up to speed with the `git reset` command which does this (and other things). * Use another work tree attached to the same repository. This is sort of a hack (even though it's official) and works only on POSIX systems (having true symlinks on their filesystems). Can be done using the git-new-worktree [1] script. > 3. > > What's up with the way Git handles folders? If I create a new > folder, it is not displayed in Git's status report. Does Git simply > not care about folders? Git does not explicitly track directories. A directory only become tracked when you `git add` at least one file in it (as a byproduct of tracking that file). This topic has been beaten to death already so please search this group's acrhives (using Google's web front-end for it, for instance) for git+tracks+content. 1. http://stackoverflow.com/a/1283818/720999 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
