[OT] DVCS

[Bruno Medeiros]

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