3 ms·
Squash was the thing that convinced me that the emperor has no clothes. Realizing that I was going to either have to train every junior, every four-month commu
by Pxtl 6y ago
Squash was the thing that convinced me that the emperor has no clothes. Realizing that I was going to either have to train every junior, every four-month community-college student brought in on co-op to modify their history in an awful UI with tons of gotchas, or I would have to accept the downsides of squash?
It's so stupid.
Git desperately needs a layer above the commit that groups related commits together into a semantically commit-like object that you can show in history and jump to its HEAD and cherry-pick. Because the squash is a dumb hack, and meticulously editing your history is not productive work.
I want squash. But I want squash without all the boneheaded implementation-detail downsides of squash. I want squash where I can put up a PR and keep working and then not have to deal with the cherry-pick pain if I want to build off that work after it merges. I want squash where I can leave the branch up after the merge and still see that it's behind the main branch.
But git's simple "everything is a commit" model makes that impossible.
- operator-name 6y agoCan't you achieve something similar with `--no-ff` and tags?
- Pxtl 6y agoA tag defines an endpoint, not a group of related commits. Yes, I could roll my own adhoc layer on top of git but it wouldn't have any tooling support. "Well, you see you can infer the start of the rangE of commits for this feature by going back to the previoNOOOOOPE
- operator-name 6y agoLeaving branches around would also work depending on the adhoc implimentation. I thought tags would be nicer as they'd be less than leaving thousands of branches. > Yes, I could roll my own adhoc layer on top of git but it wouldn't have any tooling support. Most git commands are ad hoc shell scripts built on git's internal data types. I can't see why adding your own would be that bad, a lot of external git tooling does this.
- eMGm4D0zgUAVXc7 6y ago> Git desperately needs a layer above the commit that groups related commits together into a semantically commit-like object that you can show in history and jump to its HEAD and cherry-pick. It's called a "branch" :) The commit-like object to represent it is the merge commit. If you need to group related things in a branch in a more fine-grained fashion then do sub-branches and merge them into the branch with "--no-ff" so you get a merge commit for each to describe them.
- u801e 6y ago> Git desperately needs a layer above the commit that groups related commits together into a semantically commit-like object that you can show in history That's what a merge commit does. The first parent is the base commit and the second parent is the head of the branch that was merged into the base branch. So, if you run git log first_parent..second_parent, you would see a list of related commits (related by being in the same branch).