On 10/11/2010 10:20, "Jérôme M. Berger" wrote:
Bruno Medeiros wrote:
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/.
Ah, but it is a many-times issue. It is even an every-times issue.
The problem here is that you need to remember to add the appropriate
option each and every time you want to commit. Proper interface
design would be to have the common usage be the default and have an
option to enable the complex usage (especially for the most common
command).
Additionally this makes it a lot more difficult to move back and
forth between several systems: imagine if all VCSes required special
options to do a simple commit, now each time you want to commit, you
need to remember whether this particular VCS requires an option and
which option you need to add to get the simple behaviour.
Moreover, this is just the tip of the iceberg. The whole git UI is
"designed" like that and full of small irritations and inconsistencies.
Jerome
Well, yes, it is every-times with regards to having to add the extra
commit option. But it is just 3 extra characters, and I'm guessing it is
quite easy to remember every time (maybe a little bit less if you use
different VCS often, yeah).
I'm not saying git would not be better designed if " -a" was the
default, just that it's a very unimportant in terms of comparing VCS's.
(It matters even less to my usage of VCS, since almost always I use
Eclipse's graphical interface, which has a common behavior for the basic
operations in all popular VCS. :) )
--
Bruno Medeiros - Software Engineer
