3 ms·

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 decen

by mbrock 11y ago

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

karyon 11y ago
> 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.
- mbrock 11y ago
  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...
prodigal_erik 11y ago
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?
- mbrock 11y ago
  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.

by mbrock 11y ago

karyon 11y ago

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

mbrock 11y ago
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...

prodigal_erik 11y ago

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?

mbrock 11y ago
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.