News for hackers. Stuff that matters.
Re:Rob Pike on good commit messages (2014) by Pxtl on Thursday December 19, 2019 @12:15PM (#21836871)
Yeah, I just mean the PR process auto-squashes/rebases instead of merging, so that junior developers don't have to think about it.

The problem is that if somebody leaves the branch up (delete-on-merge is obviously preferred), or derivative experimental branches, you can't tell if it's been merged or not because the commit hashes are different after the rebase. The branch list has become a scary basement.

Re:Rob Pike on good commit messages (2014) by bendavis381 on Thursday December 19, 2019 @02:10PM (#21838153)
Check out how phabricator handles this. It's essentially what you're asking for: https://secure.phabricator.com/phame/post/view/766/write_rev...

TL;DR: PRs are not based off a diff between master and a remote branch. Instead, phabricator sends up patches to code review and when approved, the Phabricator tooling handles the rebase locally. No remote branches and clean history.

Re:Rob Pike on good commit messages (2014) by Pxtl on Thursday December 19, 2019 @03:33PM (#21838948)
That's an interesting fix although I'm unsure about the sense in discouraging pushing changes.

It seems like the chief benefit they tout - clean history - is already handled by the auto-squash-and-delete approach. The real problem is the difficulty in cleanup of secondary or undeleted branches.

It isnt' really what I was asking for, though. What I want is a "soft-squash" where the intermediate commits aren't deleted, rather they're just hidden from history. The ability to draw a dotted line around a region of the DAG and say "treat this blob like it was one commit for all intents and purposes unless I say otherwise.