this post was submitted on 28 Aug 2024
528 points (97.1% liked)
Programmer Humor
32568 readers
747 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
That could happen if the base branch has changed a lot since the last time you rebased against it. Git may make you resolve new conflicts that look similar to the last time you resolved them, but they are in fact new conflicts, as far as git can tell.
All it can take is one commit in the parent branch. If your branch has many commits because you're a commit freak then your fucked.
Only if there are changes in the same files and on the same lines in both branches. And if you're a commit freak, you should probably be squashing/amending, especially if you're making multiple commits of changes on the same lines in the same files. The
--amendflag exists for a reason. No one needs to see your "fixed things", "changed things again", "fixed it for real" type commits.What I do locally on my branch is my own business.
Honestly, when doing a merge/pull request into the parent branch, that's when you squash. You don't need the entire history of a development branch in main.
Lol ok, but don't expect git to read your mind. Like I said earlier, if people take a day or two to understand the tool, they can adjust their personal workflows to work better within the confines of git.
I agree.
Unfortunately, from experience, nobody seems to have time for that. They just learn git pull, push, add, commit and merge and that's about it.
Sometimes they'll use checkout and end up in detached head and have a panic attack. That's when I come in. lol