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.
