[OT] DVCS

Bruno Medeiros brunodomedeiros+spam at com.gmail
Tue Nov 9 06:15:29 PST 2010


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


More information about the Digitalmars-d-announce mailing list