Sometimes I look at the memes around here and wonder wtf y’all are doing. Like, neither my code nor the code at the place I work at are perfect. But I don’t think I’ve ever seen a merge do this. Maybe some of the most diverged merges temporarily had a lot of errors because of some refactoring, but then it was just a few find + replaces away from being fixed again. But those were merges where multiple teams had been working on both the original and the fork for years and even then it was usually pretty okay.
It’s really easy to make a gigantic mess using git if you don’t know what you’re doing. As soon as you learn to keep your history mostly linear all those issues go away.
Jokes on merge… when a rebase editing goes wrong after +15 commits and six hours, and git hits you with a leadpipe: “do it. Do it again, or reassemble your branch from the reflog.” I.e. you commited a change very early, went over bunch of commits resolving/fixing/improving them and at middle way forget if you should commit --amend or rebase --continue to move forward. Choose wrong, and two large change-sets get irreversilbly squashed together (that absolutely shouldn’t), with no way to undo. Cheers. 👍
I consider myself above average in terms of Git know how. But I’ve come across situations using rebase where you’re stuck resolving the same conflicts over several commits.
I still don’t understand that part quite well.
This doesn’t happen when you do a normal merge though. Making it easier to manage
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.
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 --amend flag 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.
What I do locally on my branch is my own business.
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.
Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.
Works great if you’re willing to lose the commit history on your branch, which obviously isn’t always the case.
The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes “at once.”
Holy shit! I never took the time to read about it rerere. But it all makes sense now.
However, it’s still a lot of extra steps for what could otherwise be really simple with a regular merge.
Is there really a big advantage in using rebase vs merge other than trying to keep a single line of progress in the history? It’s it really worth all the hassle? Especially if you’re using a squash merge in a pull request…
I don’t think rerere applies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.
To be fair, this is also how VS looks when you open a project fresh from the clone. Or after updating .net versions. .NET is awful about losing references and then claiming thousands of errors. Sometimes just running the build will fix it by relinking the DLLs it couldn’t find.
But also yes, VS with a team can be “fun” if people don’t sync their formatting settings. I once had a junior that kept converting spaces to tabs on every file he’d touch. You’d get it fixed and then he’d screw up his settings again with a VS update or something.
I literally make a new branch. clone, and use an external merge tool (beyond compare) when my branch has fallen too far behind. I don’t trust any of the automated processes.
In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).
This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.
Also, git pull --rebase is your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.
Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.
I have seen some juniors really shoot themselves in the foot with rebasing, and I’ve been there as well before. I agree it can be useful, but it definitely requires understanding of what is going on :P
I guess the joke implies that automated (or incorrect manual) conflict resolution causes code that doesn’t compile. But still not git’s fault. They should probably have merged earlier and in rare cases where that wasn’t possible, you have to bite the bullet and fix this stuff.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
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.
Sometimes I look at the memes around here and wonder wtf y’all are doing. Like, neither my code nor the code at the place I work at are perfect. But I don’t think I’ve ever seen a merge do this. Maybe some of the most diverged merges temporarily had a lot of errors because of some refactoring, but then it was just a few find + replaces away from being fixed again. But those were merges where multiple teams had been working on both the original and the fork for years and even then it was usually pretty okay.
CS students
This is true. I got really good at fixing merge conflicts in college
You kinda have to when half of your “team” is barely even able to write code.
It’s really easy to make a gigantic mess using git if you don’t know what you’re doing. As soon as you learn to keep your history mostly linear all those issues go away.
Narrator: But it could, in fact, hurt him…
Jokes on merge… when a rebase editing goes wrong after +15 commits and six hours, and git hits you with a leadpipe: “do it. Do it again, or reassemble your branch from the reflog.” I.e. you commited a change very early, went over bunch of commits resolving/fixing/improving them and at middle way forget if you should
commit --amendorrebase --continueto move forward. Choose wrong, and two large change-sets get irreversilbly squashed together (that absolutely shouldn’t), with no way to undo. Cheers. 👍You need to merge more often.
Rebase. That’s where the real trauma is.
And the branch should be alive a shorter period
Absolutely
Neither rebasing nor merging should cause trauma if everyone on the team takes a day or two to understand git
I consider myself above average in terms of Git know how. But I’ve come across situations using rebase where you’re stuck resolving the same conflicts over several commits.
I still don’t understand that part quite well.
This doesn’t happen when you do a normal merge though. Making it easier to manage
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 usually squash my local into a single commit, then rebase it onto the head of main. Tends to be simpler
Ditto.
You could try making enabling git’s
rererefunctionality, which stands for “reuse recorded resolution”. This should largelyhttps://git-scm.com/book/en/v2/Git-Tools-Rerere
https://stackoverflow.com/a/49501436
Yeah I saw someone else’s answer and I totally learned something new today.
Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.
Works great if you’re willing to lose the commit history on your branch, which obviously isn’t always the case.
Yeah that’s what I did as a workaround. Reset (soft) to the first parent commit and do a single commit with all the changes.
The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes “at once.”
You can improve the situation with git rerere
Holy shit! I never took the time to read about it rerere. But it all makes sense now.
However, it’s still a lot of extra steps for what could otherwise be really simple with a regular merge.
Is there really a big advantage in using rebase vs merge other than trying to keep a single line of progress in the history? It’s it really worth all the hassle? Especially if you’re using a squash merge in a pull request…
I don’t think
rerereapplies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.You and I have very different opinions on what is a reasonable expectation for our respective teams.
You think it’s unreasonable for a software developer to take one to two days to learn a tool that’s basically ubiquitous in their field?
No, I think it’s a perfectly reasonable thing to do, my coworkers on the other hand…
If I saw this in my code… I’d just… I’d have a mental breakdown
To be fair, this is also how VS looks when you open a project fresh from the clone. Or after updating .net versions. .NET is awful about losing references and then claiming thousands of errors. Sometimes just running the build will fix it by relinking the DLLs it couldn’t find.
But also yes, VS with a team can be “fun” if people don’t sync their formatting settings. I once had a junior that kept converting spaces to tabs on every file he’d touch. You’d get it fixed and then he’d screw up his settings again with a VS update or something.
Try programming in Dart. Dart’s static analyser and package manager will go nuts 0.0001 seconds before the fucking packages load
he was doing gods work
No
Tabs > spaces
Tabs does allow you to set the spacing you need.
Spaces are like hardcoding passwords
Yeah, tabs are larger spaces, what’s your point?
/s
You may be right, but I still have an unreasonable hate for tabs in code
Tabs for indenting and spaces for aligning. There. Everybody wins and loses.
This way the code always looks aligned and if you prefer 4 spaces for a tab instead of 2 or 3 or 8 you can just set it in your IDE.
Crisis averted!
And I for spaces.
Let’s hate both and be mad at the client?
I like the way you think.
Both tabs and spaces are stupid.
It’s ridiculous that in 2024, code formatting is still embedded in the source instead of being a style you apply.
I literally make a new branch. clone, and use an external merge tool (beyond compare) when my branch has fallen too far behind. I don’t trust any of the automated processes.
rerere makes resolving these almost bearable
POV: Your codebase undergoes a full refactor for every feature
My codebase doesn’t have features, I’ve been refactoring hello world for 25 years.
Git flow eliminated 95% of merging issues for my team
I suck at git.
I’m currently rebasing 17k commits into my branch. I’m letting it run overnight.
I’m disgusting.
oof.wav
I know this is a joke, but those errors/warnings/messages screenshot is not from git. That looks more like results from a compiler of some sort.
When people do a bunch of bulk renames on every commit, then you get this kind of problem a lot. But yeah still not gits fault
In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).
This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.
Also,
git pull --rebaseis your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.
I have seen some juniors really shoot themselves in the foot with rebasing, and I’ve been there as well before. I agree it can be useful, but it definitely requires understanding of what is going on :P
What I suggest is not the same as using
git rebase. It’s pretty automatic and easily abortable.Looks exactly like Visual Studio 2022.
I guess the joke implies that automated (or incorrect manual) conflict resolution causes code that doesn’t compile. But still not git’s fault. They should probably have merged earlier and in rare cases where that wasn’t possible, you have to bite the bullet and fix this stuff.
ALL KINDS OF SUFFERING ARE MERGE CONFLICTS
GIT IS OUR MIRROR
REBASE IS HEAVEN