On 02/11/15 19:40, Richard Hipp wrote:
On 11/2/15, Michal Suchanek <hramr...@gmail.com> wrote:
when you
want to separate the changes you want to commit and changes you want
to ... keep uncommitted to do more work on them this is quite
useful. And don't tell me nobody ever mixes unrelated and possibly
conflicting changes in the same working directory.
People do that. But it is much more easily accomplished by simply
listing the files you want to commit on the "commit" command line.
That's what every other VCS in the world other than Git does. And it
works great. And it does not require the added confusion of a staging
area.
I've worked with software engineers that have got very confused with
Git, but the staging area isn't what they got confused about. Where they
got into tangles was because of the distributed nature of the
repositories. I'd say git staging is a useful feature.
But on the other hand, you should not be checking-in untested changes.
The proper way to do incremental check-ins is to stash the whole lot,
then pull out individual pieces from the stash and test and commit
them separately.
True, if you're talking about trunk say, and you have a policy where you
try to ensure trunk is always correct. But if you are working on a
feature branch, and that feature is part way through development,
incomplete in places, knowingly broken in other places, then why would
you have a rule of not checking in untested changes here?
Regards,
Paul.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
