Hacker News Reader

Comment by karyon | Hacker News Reader

You lose a whole lot of development history information. You have no chance of finding out why these five lines of code came to be when all your commits touch hundreds or thousands of lines. Maybe the intent of the code should've been in a comment, but if there are none, it's nice to have commit messages as a backup.

Also, bisecting (and then finding the actual fault in the code) gets harder the larger the commits are.

View on HN

> You lose a whole lot of development history information

What information do you lose, and why is that a problem? The feature commit tells you everything you need to know. Beneath those details tend to be irrelevant minutiae.

Let's imagine an editor that made one commit for each key press you type, or every time you save a file. That would be the closest thing to true history. I might accuse your practice of not committing that level of detail with "losing a whole lot of development history", and it would be true but only in a banal sense.

How an author built up their feature commit is almost never (and shouldn't be) relevant to everyone else. What's relevant to others is how they changed the repository and why. A good feature commit or commit series should stand alone.

One thing you lose is history across filename changes. Git can track renaming, but if in the same commit you also change the contents of the file, git has no way to figure that out. Separate it over two changes, and git knows what happened.

For that reason I also try to spread big refactorings over a couple of commits (always with the code working after each commit, of course).

I also like to have formatting changes in a separate commit. Mixing functional changes with formatting changes means every line in the file has changed, and the functional changes become invisible. (Though commit hooks that demand an (Jira) issue nr in the commit message make this hard.)

Isn't this mostly true if you both change the file name and change most of the file's content? In which case it might be best to just see it as a deletion and creation anyway?

If the file still serves roughly the same functionality, just is refactored form, I think it's nice if the old version still shows up in the history.

You're going too far in the other direction in an attempt to counter. A single commit per feature is bad because you lose context that links changes together. A commit every keystroke is bad because you again lose the context that links changes together. A commit should be a logical grouping of something you accomplished towards the overarching feature. In my mind, commits should happen any time you could envision yourself at a point where you could leave for the day and come back to continue the next without having any difficulty spinning back up (what was I trying to do here, again?) Sometimes that overlaps with the feature, if your feature is really small, but often it won't.

I often don't want to record my development history in the master branch because it's messy. Instead I squash my work into a single cohesive commit with a decently well written commit message.

I'm not convinced that more commits generally make it easier to understand why code changed. Often when I blame a line, if I see it was changed by a cohesive feature commit, that tells me all I need to know—and if something's wrong with it, I can say "hey Joe, you broke the frobber when you implemented the new gizmo."

> I often don't want to record my development history in the master branch because it's messy. Instead I squash my work into a single cohesive commit

personally i rebase my commits into fewer ones so the result is a reasonable compromise between how-the-code-actually-evolved (which is messy, true) and a clear, simple progression from start to completion of the feature (one single commit if taken to the extreme).

> I can say "hey Joe, you broke the frobber when you implemented the new gizmo." that breaks if joe is not available anymore or the change is complex (or old) enough that the detailed history would help debugging, but joe doesn't have the branch lying around anymore because he deleted it or switched machines etc.

There are certainly advantages to a single commit per feature :) I just think having more information available through more commits is a good thing, and i don't see large disadvantages of having larger amounts of commits, provided you really do squash those "fix last commit" commits etc. to keep the commit count reasonable.

Mostly agreed. I have some notion that a commit "should" be a well-defined change in terms of program behavior, so if I can develop a feature in actual stages, I like to make separate commits. That's often the case with complex features.

Multiple commits can be confusing too, when commit messages aren't good, so I think making coherent changes is a problem beyond commit frequency...

You're throwing away your backup of info which now exists nowhere outside Joe's head. What happens if he gets poached next quarter, or even just forgets the tricky part of the new gizmo?

I'm not convinced that having more of Joe's intermediate commits would help very much with that problem. If I don't understand his code or what it's supposed to do, I probably won't understand his commit messages either.

Reply on news.ycombinator.com