[OT] DVCS

["Jérôme M. Berger"]

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
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20101110/3af68064/attachment.pgp>