[OT] DVCS

Alexey Khmara alex.khmara at gmail.com
Wed Nov 17 12:59:38 PST 2010


"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.


More information about the Digitalmars-d-announce mailing list