[OT] DVCS

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

Alexey Khmara wrote:
> "add + commit" is not a bad design at all. It is just design choice,
> and it also about "patch control system", that allows more logical
> commit history and more precise control over VCS. It allows to code
> all things you want and place into commit only part of your changes.
> You even can stage part of file - if, for example, you done two
> logically different changes without commit between them. May be, good
> analogy will be reading file with one command versus "open-read-close"
> sequence - simplicity versus good control.
> 
> This feature allows very comfortable, free coding style - you write
> what you want ad understand now, and later you can divide your changes
> to logically related sets. You do not controlled by limits imposed by
> VCS - "work on one feature, commit, work on another". Instead VCS
> works in your style and rhythm. Usually you don't want run "commit
> -a". Instead when you run "git status" you see several files that you
> do not want to commit right now. So you use "add + commit" sequence,
> may be - several times to commit different changesets as distinct
> entities with distinct comments.
> 
> I think it's very good point of view - to track not file versions,
> patchsets that represent something meaningful - new features, bugfixes
> etc, and have VCS follow your practices and rhythm - and have
> understandable version tree at the end.

	This has nothing to do with Git's staging area. Mercurial also
tracks patchsets that represent something meaningful and has full
support for partial commits (with record or crecord) so you can
"write what you want and understand now, and later [...] divide your
changes to logically related sets". On the other hand, you are not
forced into this model when you know you have only worked on a
single feature and want to commit it.

		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/20101117/8c785e14/attachment.pgp>