1114
Rebase Supremacy
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 04 Apr 2024
1114 points (98.1% liked)
Programmer Humor
19622 readers
71 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
I prefer to rebase as well. But when you're working with a team of amateurs who don't know how to use a VCS properly and never update their branc with the parent branch, you end up with lots of conflicts.
I find that for managing conflicts, rebase is very difficult as you have to resolve conflicts for every commit. You can either use rerere to repeat the conflict resolution automatically, or you can squash everything. But when you're dealing with a team of Git-illiterate developers (which is VERY often the case) you can either spend the time to educate them and still risk having problems because they don't give a shit, or you can just do a regular merge and go on with your life.
Those are my two cents, speaking from experience.
I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It's good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don't know how to edit them.
Honestly, I'm pretty sure 99.9% of git users never really bother with the git history in any way that would be hindered by merging.
Git has a ton of powerful features, but for most projects they don't matter at all. You want a distributed consensus, that's it. Bothering yourself with all those advanced features and trying to learn some esoteric commands is frankly just overhead. Yes, you can solve great problems with them, but these problems almost never occur, and if they do, using the stupid tools is faster overall.
@agressivelyPassive @technom That's a self-fulfilling prophecy, IMO. Well-structured commit histories with clear descriptions can be a godsend for spelunking through old code and trying to work out why a change was made. That is the actual point, after all - the Linux kernel project, which is what git was originally built to manage, is fastidious about this. Most projects don't need that level of hygiene, but they can still benefit from taking lessons from it.
To that end, sure, git can be arcane at the best of times and a lot of the tools aren't strictly necessary, but they're very useful for managing that history.
Yup, once you can use git with good hygiene, it opens up the door to add in other tools like commitizen and semantic-release, which completely automates things like version number bumps and changelog generation.
I fucking hate auto-generated changelogs, so I consider that a downside.
I'd still argue, that the overhead is not worth it most of the time.
Linux is one of the largest single pieces of software in existence, of course it has different needs than the standard business crap the vast majority of us develop.
To keep your analogy: not every room is an operating room, you might have some theoretical advantages from keeping your kitchen as clean as an OR, but it's probably not worth the hassle.
To keep your analogy, most people's git histories, when using a merge-based workflow, is the equivalent of never cleaning the kitchen, ever.
No, it's not. And you know that.
Seriously, ask yourself, how often did the need arise to look into old commits and if it did, wasn't the underlying issue caused by the processes around it? I've been in the industry for a few years now and I can literally count on one hand how often I had to actually look at commit history for more than maybe 10 commits back. And I spend maybe 10min per year on that on average, if at all.
I honestly don't see a use case that would justify the overhead. It's always just "but what if X, then you'd save hours!" But X never happens or X is caused by a fucked up process somewhere else and git is just the hammer to nail down every problem.
Literally every single day. I have a git alias that prints out the commit graph for my repositories, and by looking at that I can instantly see what tasks my coworkers are working on, what their progress is, and what their work is based on. It's way more useful than any stand-up meeting I've ever attended.
I've been in the industry for nearly 15 years, but I can say that the last 3 years have been my most productive, and I attribute a lot of that to the fact that I'm on a team that cares about git history, knows how to use it, and keeps it readable. Like other people have been saying, this is a self fulfilling prophecy - most people don't care to keep their git history readable, so they've only ever seen unreadable git histories, and so they think git history is useless.
What overhead? The learning curve on rebasing isn't that much steeper than that of merging or just using git itself. Take an hour to read the git docs, watch a tutorial or two, and you're good to go. Understand that people actually read your commit messages and take 15 extra seconds to make them actually useful. Take an extra minute before opening an MR to rebase your personal branches interactively and squash down the "fixed a typo" and "ran isort" commits into something that's actually useful. In the long run this saves time by making your code more easily reviewable, and giving reviewers useful context around your changes.
No, having a clean, readable git history literally saves my team hours. I haven't had to manually write or edit a changelog in three years because we generate it automatically from our commit messages. I haven't had to think about a version number in three years because they're automatically calculated from our commit messages. Those are the types of things teams sink weeks into, time absolutely wasted spent arguing over whether this thing or that is a patch bump or a minor bump, and no one can say for sure without looking at diffs or spinning up multiple versions of the code and poking it manually, because the git log is a tangled mess of spaghetti with meatballs made of messages like "finally fixed the thing" and "please just work dammit". My team can tell you those things instantly just by looking at the git log. Because we care about history, and we keep it clean and useable.
I gotta say, I was with you for most of this thread, but looking through old commits is definitely something that I do on a regular basis... Like not even just because of problems, but because that's part of how I figure out what's going on.
The whole reason I keep my git history clean and my commit messages thoughtful is so that future-me (or future-someone-else) will have an easier time walking through it later, because that happens all the time.
I'll still almost always choose merge instead of rebase, but not because I don't care about the git history-- quite the opposite, it's really important to me in a very practical way.
@agressivelyPassive You should still clean your kitchen though, that's my point.
Did I say anything otherwise?
We use history and blame a lot
Only users who don't know rebasing and the advantages of a crafted history make statements like this. There are several projects that depend on clean commit history. You need it for conventional commit tools (like commitzen), pre-commit hook tools, git blame, git bisect, etc.
Uuuh, am I no true Scotsman?
Counter argument: why do you keep fucking up so bad you need these tools? Only users who are bad at programming need these. Makes about as much sense as your accusation.
You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools. I literally never used pre-commit hooks or bisect in any semi-professional context. And I don't know a single project that uses them. And before you counter with another "well u stoopid then" comment: the projects I've been working on were with pretty reputable companies and handled literally billions of Euros every year. I can honestly say, that pretty much everyone living in Germany had his/her data pushed through code that I wrote.
That's a terrible and disingenuous take. I'm saying that you won't understand why it's useful till you've used it. Spinning that as no true Scotsman fallacy is just indicative of that ignorance.
And you keep repeating that falsehood. Isn't that the real no true Scotsman fallacy? How do you even pretend to know that nobody needs it? You can't talk for everyone else. Those who use it find it useful in several other ways that I and others have explained. You can't just judge it away from your position of ignorance.
Why would you want to edit your commit history? When I need to look at it for some reason, I want to see what actually happened, not a fictional story.
Because when debugging, you typically don't care about the details of
wip,some more stuff,Merge remote-tracking branch 'origin/master',almost working,Merge remote-tracking branch 'origin/master',fix some testsetc. and would rather follow logical steps being taken in order with descriptive messages such ascomponent: refactor xyz in preparation for feature,component: add do_foo(),component: implement feature using do_foo()etc.You can have both. I'll get to that later. But first, let me explain why edited history is useful.
Unedited histories are very chaotic and often contains errors, commits with partial features, abandoned code, reverted code, out-of-sequence code, etc. These are useful in preserving the actual progress of your own thought. But such histories are a nightmare to review. Commits should be complete (a single commit contains a full feature) and in proper order. If you're a reviewer, you also wouldn't want to waste time reviewing someone else's mistakes, experiments, reverted code, etc. Self-complete commits also have another advantage - users can choose to omit an entire feature by omitting a commit.
Now the part about having both - the unedited and carefully crafted history. Rebasing doesn't erase the original branch. You can preserve it by creating a new branch. Or, you can recover it from reflog. I use it to preserve the original development history. Then I submit the edited/crafted history/branch upstream.
How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.
In a small team at a small company it becomes my problem pretty quickly, since I'm the only one that actually has some clue about what git does.
This. When they get any sort of conflicts in their pull request, it becomes MY problem because they don't know what to do.
Heaven forbid my teammates read any documentation or make any attempt to understand the tooling necessary to do their job.
That being said, I taught my dumbass git-illiterate team members a rebase workflow, with the help of the git UI in Pycharm. Haven't had any issues with merge conflicts yet, but that might just be because they're too scared to ask me for help any more
I don't want squashed commits. It makes git tools worse (
git bisect,git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don't want to throw all of that away.But yeah, I don't actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.
Ah thanks.