this post was submitted on 26 Aug 2023
1220 points (98.4% liked)
Programmer Humor
32725 readers
74 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yep, in part, I do. Say I'm working on
feature
which branched off frommain
. Time's gone by, and there have been commits on bothfeature
andmain
. I want to integrate (not I am very carefully not using the wordmerge
!) the commits that exist onmain
into myfeature
branch so that I can use them. You can make a merge commit to do so, but there's no point in doing so - agit pull --rebase
will have the same effect ("My local branch contains both the changes from the upstream, then the changes that I myself have made 'on top of' them") without requiring a merge commit.But really, what one chooses to do in the privacy of one's own branch is no concern of mine. I can advise and opine, but it doesn't really affect me. What does affect me is when people insist on merging into
main
. That really irritates me, because it results in horrible tangled non-linear history like this. Ideally, the history ofmain
should be a linear history of changes which each follow on from one another, and a commit and a change are in 1:1 correspondance:main
. They are maybe useful in the PR, but the change as seen inmain
should only contain the finished polished-up result.GitHub's confusingly named "Squash And Merge" (it's a "merge" in the
git merge
sense, but it doesn't create a Merge Commit! "Squash and commit" or "Squash and push" would be more accurate) results, I think, in the outcome - a single commit on theHEAD
of the target branch containing the result of the change. And if that happens, then I don't care if you've been pulling in changes frommain
tofeature
via Merge commits or (correctly IMO) viagit pull --rebase
- because, whatever you've done, your development history will be (correctly) invisible from the commit onmain
.(I say "I think" there because I've only recently started using GitHub in a professional capacity. For the decade prior to this I worked at a Big Tech company which had its own in-house Code Review tools which - probably not by coincidence - aligned a lot more closely with how I think about how Git history should be structured)