Re:Git email flow vs. GitHub flow
by earthboundkid on Monday March 29, 2021 @11:22PM
(#26630975)
When someone invents the git killer, it will have a feature called “subcommits” that will be blindingly obvious in hindsight.
[ Parent
| on HN ]
Re:Git email flow vs. GitHub flow
by oftenwrong on Tuesday March 30, 2021 @03:55AM
(#26632147)
If I've correctly understood what you mean, I've wanted this for some time now. A way to preserve history while adding a single, linear integration of changes.
Re:Git email flow vs. GitHub flow
by renewiltord on Tuesday March 30, 2021 @01:52AM
(#26631560)
You get this by forcing merge commits for every non-single-commit change.
Re:Git email flow vs. GitHub flow
by earthboundkid on Tuesday March 30, 2021 @11:29AM
(#26635741)
Sure, you can use git to do this, but the git killer will have it as an expected capability.
I also think that octopus merges are basically always a disaster because they can't be meaningfully reviewed and put your repo into an unknown state. Maybe there's some way to get the advantages of merge commits (preserve all history!) without the disadvantages (jumble all history!).
Not sure why you are being downvoted. You actually can use merge commits this way, by viewing the diff produced by
git diff $merge_commit^...$merge_commit^2
when interested in whole change-set introduced by a branch or looking at individual commmits when interested in well, individual commits.
Re:Git email flow vs. GitHub flow
by WorldMaker on Tuesday March 30, 2021 @12:10PM
(#26636368)
Yup, and you can use --first-parent to git bisect, git log, git praise to interact at the "macro-level" of those merge commits by default, and dive in to the fuller graph only as necessary.