Hacker News Reader

Comment by city41 | Hacker News Reader

Just to play devil's advocate: this does force people to be more mindful of their commits. This is a good thing. Each commit should be a cohesive, logical change to the codebase. Such that if the change is later undesired, simply reverting one commit should completely remove it. This is very good practice for when you use git at your day job. In this scenarios, your 'watchers' are your coworkers, and they will rightfully get upset if you clog the repo with a bazillion haphazard commits.

View on HN

I agree this is the underlying issue but I disagree with your solution. One of the last big problems none of the popular SCM's has really fixed is separating commits that are "checkpoints" for the developer from those that should be used as documentation of the project history (e.g. "Closes bug X").

There are times I end up doing a commit just to switch from my laptop to desktop. In Mercurial I end up with a million commits with the message "merge" b/c I really just did a pull of someone else's code and it forces you to do a commit just to get synchronized with the master (even with no meaningful conflicts).

I wish I could nuke all those ugly checkpoint commits and bundle them into a single commit with an intelligent comment when I push to the main server, but that's just not the standard workflow.

git rebase -i can handle your last request (interactively combine/remove/move history).

In fact, git can also handle your second wish by having simply creating a "sync" branch pointing to that extra commit, then when you switch to between your laptop and desktop, pull the sync branch, check out the commit (apply it to your working directory), then switch back to the master branch and continue working (the commit never appears in the master branch).

Git rebase would handle the "forced commit on merge with no meaningful conflicts".

hope I don't sound like too much of a fanboy :)

+1, git rebase -i is amazing for this

To add to kenmazy's reply: another way git allows you to have "checkpoint commits" is to create a new branch. Commit against this branch all you want. Then when you are done with your work, return to the main branch and do a "git merge -squash <yourworkbranch>". git will pull all the commits you did in the feature branch into the main branch's index. You are then free to commit the whole shebang into the main branch as one commit, with whatever commit message you want.

I've never used Mercurial, so I don't know if it has any equivalent to that.

I suppose this (and the other responses) is about what I would expect: it's possible in Git if you know what you're doing. Based on my very limited Git experience, I would have expected it to take more flags to accomplish :) (It probably is possible in Mercurial in some way, too.)

But then that gets back to the original problem: how do you get people to do that so github watch lists only contain worthwhile comments?

Yeah, it's a problem. Either we need to get better at our source control tools, or our tools need to become simpler to use. I'm not sure which is the right approach.

It might force the developers to commit more in the granular Git way, but it doesn't force bug reporters and discussions to be more mindful. Looking at my timeline, and following Backbone.js and Handlebars, about half my feed on any given day is discussion from 2 or 3 bugs on each of those projects.

So even though the committers might be mindful, doesn't mean all the users of a project are.

Reply on news.ycombinator.com