On Wed, Sep 17, 2014 at 05:52:29AM -0700, Dmitry Moscow 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.
Actually, SVN behaves the same way in regards to jumping between
branches with changes present:
~~~
% svn info|grep Relative
Relative URL: ^/trunk
% svn st
M bar
% svn diff
Index: bar
===================================================================
--- bar (revision 3)
+++ bar (working copy)
@@ -0,0 +1 @@
+Hello.
% svn switch ^/branches/b1
At revision 3.
% svn diff
Index: bar
===================================================================
--- bar (revision 3)
+++ bar (working copy)
@@ -0,0 +1 @@
+Hello.
~~~
And keep in mind that SVN only has an explicit staging step when
adding files. Furthermore, the staging area in git is not tied to a
branch, it's tied to the working area. Again, just as in SVN.
> 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.
Also for files that are just added does SVN behave exactly the same as
git.
~~~
% svn info|grep Relative
Relative URL: ^/trunk
% touch qux
% svn add qux
A qux
% svn switch ^/branches/b1
At revision 3.
% svn st
A qux
~~~
> Am I correct, or am I just confused? Why does Git work in this way?
So, if I understand you correctly you actually are confused ;) No
seriously, of course it's a valid question to ask 'why'. Interesting
though that you never ran into the behaviour when using SVN.
> 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?
It happens at the same point as when you get a merge conflict in SVN ;)
~~~
% svn info|grep Relative
Relative URL: ^/trunk
% svn cat ^/trunk/bar
% svn cat ^/branches/b1/bar
foo bar
% echo 'wibble wobble' >> bar
% svn st
M bar
% svn switch ^/branches/b1
C bar
Updated to revision 4.
Conflict discovered in file 'bar'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
(mc) my side of conflict, (tc) their side of conflict,
(s) show all options:
~~~
That is, git tells you it can't switch to the other branch without
losing your changes. Just as SVN does. They just do it in different
ways; SVN forces you to merge, git forces you to remove the changes
or commit them first.
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
Any fool can write code that a computer can understand. Good programmers
write code that humans can understand.
-- Martin Fowler
pgp8HD04VUWD5.pgp
Description: PGP signature
