On 28/10/2010 18:51, "Jérôme M. Berger" wrote:
Bruno Medeiros wrote:
But isn't the staging area similar, if not identical to SVN? I mean, in
svn you also have to do a command "svn add" to add new files to the
"sandbox". They won't get commit otherwise, right?
(note: im somewhat familiar with SVN and Git, but not with Mercurial)
No, because in Git if you make changes to an existing file, you
need to "add" that file again. In both SVN or Mercurial, you need to
"add" new files, but once a file is in the repository, any changes
to the file get committed by default (although there are ways to
commit only some files in both Mercurial and SVN and ways to commit
only some changes in Mercurial).
Jerome
I see. Well, it's not identical then, but still, it seems very similar,
since one can use "git commit -a" to do the same as "svn commit", isn't
that so? I mean, is there any aspect to Git's staging area that makes
"git commit -a" not be equivalent to "svn commit" ? (obviously for this
question interactions with Git-only features should not be considered)
My confusion here stems not so much from the discussion in this thread,
but from another discussion elsewhere on the web (not D related) where I
also saw a developer comment that Git's staging index default behavior
was more complex that necessary, and that it should be the simple thing
by default. There was an implication, from the way he said it, that this
was an issue of at least medium importance.
However, from my understanding, in the whole landscape of version
control issues and comparisons, this one seems of very low importance,
if not borderline irrelevance. Because even if a developer using Git
shoots himself in the foot with this... it will be only *once*, on the
learning phase. After that you'd know and remember to use "git commit
-a" so the mistake would not be repeated. A /one-time issue/ cannot
possibly be anywhere near in importance than a /many-times issue/.
--
Bruno Medeiros - Software Engineer
