Hacker News new | ask | show | jobs
by wcoenen 5453 days ago
I appreciate that you should have the option to choose which part of your working directory you commit. But I think the default should be to commit everything, like in SVN or mercurial. If I need to commit selectively in those systems, I'll disable some checkboxes, type in the filenames, build a changelist or use the record extension or something. The point is that I don't need to deal with it until I need it.

Also, it seems to me that git's behaviour encourages broken revisions (i.e. compiler errors, test failures) because your working directory doesn't match what you commit. And broken revisions will interfere with bisecting.

3 comments

I think committing everything in the working directory is an awful default. Few developers are disciplined enough that the contents of a working directory always make a perfect commit.

With git, how you code is a non-issue. The whole idea is that you're able to to worry about commits afterwards. The index is a wonderful tool to help you untangle the mess of code that has not yet been separated into logical pieces. Working with git is not just writing out code and then committing it. Making proper commits requires time, discipline and practice.

Part of the problem might be the mindset that a VCS is supposed to record how the development happens, but if you think about it, that does not make much sense. The actual development process of a feature or even a bugfix is often riddled with experiments, trivial mistakes, sidetracking, and other largely uninteresting issues.

Once you have thought about what is logical to record into the repository and create a commit, you can test it. Git stash allows you to put aside all other work while you run tests, and git commit --amend allows you to fix the commit until it works.

Test your commits, and you will not have broken revisions or unbisectable history.

Yes, this is legitimate criticism of git's philosophy.

However, in practice i have seen those broken revisions in svn just as well. People forget to add untracked files or they skip the final unit test run. Basically, I believe your criticism is theoretical and no problem in practice.

Git requires a bit of a learning curve to use but it's gotten far simpler than subversion for me. I used subversion for years before using git. I refuse to go back.

If you always want to commit everything use `git add . && git commit -a`.