Thread with 14 posts
jump to expanded post
if the purpose of a system is what it does then the purpose of github dot com is to make git commit history useless
‪i am insufferable advocate for gerrit but also seriously like‬
‪- the merge-based pull request workflow encourages polluting history with broken commits and fixups that should have been squashed‬
‪- it routinely misattributes corporate contributions to personal emails and vice-versa‬
‪- the squash-based pull request workflow destroys carefully-crafted history where it exists‬
‪- the merge and squash-based pull request workflows generally pollute git history with the contents of pull request descriptions, which are not necessarily good commit descriptions‬
‪- the fact it hides git committer and author names and emails everywhere means people do not notice when they are wrong or inconsistent, whether that's because of git or github dot com configuration‬
‪- you cannot fully control what email it attaches to commits attributed to you 🙃‬
‪- github just assumes your display name on your github profile should be attached to commits and gives you no option to change this‬
‪- github just assumes that that your primary login/password reset email address should go in git history and you can't completely disable this‬
‪but github dot com also goes out of its way to hide trans people's deadnames so, it;s impossible to say if its bad or not.‬
‪actually i could scream about the corporate/personal misattribution thing all day. this is awful for employees' right to make contributions to stuff outside of work. github's terrible design choices mean the only useful heuristic is that everything belongs to someone's employer‬
ceterum autem censeo, githubinem esse delendam
‪i am sure the road to hell is paved with good intentions, but a side effect of github's awful handling of all this is to promote lock-in to the platform. if the git commit history only makes sense when viewed on github dot com, it makes switching away from it less practical… ‬
@hikari I thought that was the tradeoff. You keep all development history with merge or rebasse, but have individual commits which are potentially incomplete, or squash to have each change uniform and tested but no history.
There’s a third way?
,
@leo@60228.dev
@aismallard @hikari Gerrit considers each commit to be a separate reviewable unit
@hikari it is absolutely baffling to me that GitHub doesn't allow you to review-and-approve the final commit message as part of a review. Commit messages matter! A lot!
I mean, I kinda do get it. Their crappy default generated message that everyone ignores means that ALL context about your project exists only in GitHub. Dark-UX-driven lock-in at its finest.
But UGH. How could someone build that and then sleep at night.
@groxx @hikari I’ve pretty much started, at and outside work, just squashing and merging and writing my own commit message when I merge a PR
the default sucks, I don’t know that other people are going to merge it nicely, and while there are some downsides to squashing I find it’s a lot nicer to be able to commit however the heck you want, knowing it’s only gonna be one commit in the end (and reviews are sometimes easier with more commits)