4 ms·

> 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

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

by Pyxl101 11y ago

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

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.