4 ms·

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 h

by karyon 11y ago

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.

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.
Pyxl101 11y ago
> 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.
- mcv 11y ago
  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.)
  - mbrock 11y ago
    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?
    - mcv 11y ago
      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.
- kedean 11y ago

by karyon 11y ago

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.

Pyxl101 11y ago

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

mcv 11y ago
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.)
- mbrock 11y ago
  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?
  - mcv 11y ago
    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.
kedean 11y ago