4 ms·
Hijacking the top thread to make an important point: - "Squash your commits" folks - yes, it's good to be able to revert a commit and remove entire features an
by nailer 6y ago
Hijacking the top thread to make an important point:
- "Squash your commits" folks - yes, it's good to be able to revert a commit and remove entire features and have a readable commit history.
- "Make small granular commits" folks - yes it's good to be able to bisect and see where exactly some behaviour changed.
Rather than repeat these points (which are both true), there's a better question to be asked:
Should there be a way to have a readable history and keep individual commits? Eg, 'subcommits' etc?
- git may not have these features now, but revision control systems come and go (rcs, cvs, svn, bk, hg, git)
- Or maybe it does. Or we can implement something similar on top of git as it stands.
Discuss.
- twic 6y agoI'm intrigued to see that there are (by my count) three of us making this point today. Perhaps this is an idea whose time is finally coming.
- leejo 6y agoYou can revert a merge commit by providing which side of the merge is mainline: git revert -m 1 $sha_of_the_merge_commit That provides the "revert a commit and remove entire features" use case, assuming the original feature was all encapsulated within the merge (branch) in question. You can get the "readable commit history" with: git log --no-merges You can have the best of both worlds. git has had these features for as long as I can remember, but devs have had the "NO MERGES ONLY CLEAN HISTORY" platitude repeated so often they must think git lacks an alternative.
- vollmond 6y agoThis response [0] by avar shows you can get both by using the min/max parents flags, to either see only merge commits or only code commits: [0] https://news.ycombinator.com/item?id=24687027 https://news.ycombinator.com/item?id=24687027