On Wed, 17 Sep 2014 22:25:50 +0400 Konstantin Khomoutov <flatw...@users.sourceforge.net> 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"  -- 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  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  [*] This presents a vastly different mindset from another neat DVCS, Fossil, which is detailed in section 3.8 of . I would add that while I adore Fossil my personal opinion is that most of  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.