Skip Navigation

Programmer Humor @lemmy.ml

MentalEdge @sopuli.xyz

1y ago

A classic

37 comments

I feel like I often would prefer to get the merge conflict. So many times my coworkers will somehow mess up the code I committed when resolving the conflict.
- Rebase all of your work branches onto HEAD so that conflicts require refactoring the first commit where things don't match up. This can make conflicts easier to deal with (in my humble opinion) since you deal with conflicts earlier in your commit history as opposed to at the end after ALL of your changes are made.
  Plus a linear history is super nice to work with later on.
  
  I always squash my commits before rebasing. Is your way easier? I never really seem to have a problem with merge conflicts.
- This way I can wreck their shit instead! Enjoy debugging this one Tim, you obtuse bastard!
- Dear god yes. Please just let me deal with the conflict before the kids make it worse.
  
  !usernamechecksout@lemmy.zip
- Inschools project, I once used the flag ours.
- git push -f

git push --force
Problem?
- Not for you!*
  *Since you'll be unemployed
  
  Dam, hate to work where you work. People do it here all the time and never get fired. Fucking drove me to save backups of my changes and literally would have to push my changes again afterwards. Good thing I finally found a place to work where this shit isn't practiced.

I’m usually the one managing merge conflicts, and honestly that’s how I’d prefer it. I’ve had so many instances where my code was bungled because someone didn’t take the time to actually check the conflicts.
- Best thing is to add tests if possible to make sure your code doesn't lose the added functionality.
  
  What is this, the billionaires club? Ain't nobody got time for tests!

Two new files wouldn't create a merge conflict though (unless they have the same name)?
- Git won't let the second person push if their commit history doesn't line up with the origin branch.
  It should be trivial to do a git pull --rebase to move your new commit after the upstream version, but as far as I can tell, no one on my current project remembers this (or perhaps they're using gui tools or something). Our log is full of "merge origin/main onto main".
  
  God I fucking hate merge commits.
  
  While we're at it, I like to use --autostash in addition.
- I think the idea is both are adding new files and also making changes to various files but his commits to the non-new files caused the conflict. Also, if both new files affect the same deliverable (like a DLL) then that could create a conflict in some cases (though I think that all depends on the build system).
- Sometimes git just hates you

Committing code like an a duel in an old western movie.

I always rush to finish first when I learn someone else is working on the same files. Ain't nobody got time to figure out how to merge your shit with my beautiful, perfect, new feature.

Not if you upload different files lol
- Exactly. I was going to share this with colleagues but it's wrong

Pulling changes should be trivial after you've done it a few times.

37 comments