5 ms·
I don't understand the need to rewrite history. This is a good example against that practice.
by sergiosgc 7y ago
I don't understand the need to rewrite history. This is a good example against that practice.
- azinman2 7y agoBecause it becomes more compact. Most of the time git commits are things that don’t make sense to have at a more macro level. Squashing into a single commit that represents a coherent improvement, particularly for large projects, is the best way to read its history.
- makapuf 7y agoI prefer a small branch with many individual commits (cleaned from fixups or not) and a merge with main branch which adds the whole feature. Then you can have two levels of reading.
- drchickensalad 7y agoDoesn't this still put all the commits on the main branch?
- makapuf 7y agoNo you commit in feature branches then merge to main branch.
- nitrogen 7y agoYou can keep the branch commits for detailed history, and look only at merge commits the when you don't need details: git log --first-parent -m This will show a linear history of merges, treating the merged code as being added in the merge commit. You can add -p to see the diffs.
- jcelerier 7y agoBut then does it matter at all that the date of the comment was the day where you committed the todo, or two days after when you squashed it ?
- deleted 7y ago[deleted]
- spockz 7y agoAt least these days co-authorship can be recorded in the commits.