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.

Reply via email to