Re: [git-users] Needc explanation of the differences between GIT and SVN
On Wed, 17 Sep 2014 22:25:50 +0400 Konstantin Khomoutov wrote: I was in a hurry writing my response, so it requires a number of minor corrections which are inlined. [...] > >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` Here I meant `git checkout foo`, of course. [...] > * 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). The main idea here is that contrary to centralized SCMs such as Subversion, in a DVCS such as Git, when you record a commit all you get is just a commit, and untill you push (that is, share) a branch or a tag referencing that commit (directly or indirectly) to some public place you're free to do with that commit whatever you wish: amend, delete, replace with another, replace with a series of commits and so on and so on. In other words, Git takes such a stance that the history of changes *as you have seen it* does not matter, and what matters is the resuling, possibly rewritten and prettified history you're sending upstream or pushing to a public repo. Of course, you're not required to adopt such approach to your workflow but the general idea to understand is that while a part of your project's history is truly local (not pushed anywhere) you're free to do with it whatever you want. [*] Once you've shared that history with someone things get more complicated as those who received your history might have based their own work on it by the time you decide to re-write it, so in general what has been pushed should be considered cast in stone (but of course there are exception to this rule as well). On a side note, I would add that Subversion is moving to the same direction, working on implementing what they call "shelving" [3] -- an ability to record a series of volatile commits without actually sending them to the server. > * 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. To elaborate on this point, this script allows you to have several work trees (checkouts) connected to the same repository (object store, that ".git" directory) with different branches checked out in them *in parallel,* which kind of removes your problem in the first place. I should warn you though that this workflow is not widely adopted; most folks use stash and WIP commits. [...] > 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. See also the Git FAQ [2] [*] This presents a vastly different mindset from another neat DVCS, Fossil, which is detailed in section 3.8 of [4]. I would add that while I adore Fossil my personal opinion is that most of [4] is bullshit; I just stand on the point it's very useful to be familiar with different approaches to implementing a VCS and different mindsets backing them. 2. https://git.wiki.kernel.org/index.php/Git_FAQ#Can_I_add_empty_directories.3F 3. https://subversion.apache.org/roadmap.html 4. http://fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki -- 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.
Re: [git-users] Needc explanation of the differences between GIT and SVN
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 Cbar 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
Re: [git-users] Needc explanation of the differences between GIT and SVN
On 17 Sep 2014 17:29, "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. > > Imagine I have made some changes in my working dir. If I switch to another branch, the changesremain, which is very unusual, from an SVN point of view. This means that uncommitted changes areshared 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. Branches are actually just pointers to commits, so yes, they differ in that. > > 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. You should understand that while in SVN, committing has one step (svn add immediately commits your files), git does the same in two: you add your changes to the staging area (think of this as a pre-commit area), then do the actual commit. In SVN, you tell the VCS »commit this, this and this file«. With Git, you write list of the changes (»commit the changes of this file, commit this line from this file«), then, when you think your list is fine, you give your paper (the staging area) to the VCS. > > Am I correct, or am I just confused? Why does Git work in this way? > > 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? AFAIR, branches in SVN are actually two separate directories, with — initially — the same files, and branching itself is an actual commit. In Git, as I said before, a branch is merely a pointer to a commit, thus, your source tree doesn't change due to branching. > > 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? > > -- > 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. All in all, you should stop comparing SVN and Git, they differ in too many things. [1] is somewhat old and unmaintained, but I still suggest you to read it. I hope others may post some similar or better artices. [1] http://git.or.cz/course/svn.html -- 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.
Re: [git-users] Needc explanation of the differences between GIT and SVN
On Wed, 17 Sep 2014 05:52:29 -0700 (PDT) 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. >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.
[git-users] Needc explanation of the differences between GIT and SVN
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? 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? -- 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.
