4 ms·

Personally I love the feeling of pushing up a PR and realizing that the branch I thought was done actually has several weeks of merge conflict resolution to do.

by munk-a 3y ago

Personally I love the feeling of pushing up a PR and realizing that the branch I thought was done actually has several weeks of merge conflict resolution to do. Nothing quite like it to make one feel alive.

hinkley 3y ago
I love the people standing outside my cube or saying "hey hinkley" in chat because even though I'm "good at merges" by developer standards I still have maybe a 90% success rate. And so I've either broken their shit, or they broke someone else's and they know I'm the closest we have to a git surgeon so they've come for a consult.
- munk-a 3y ago
  Yup ditto (and I'd assume most participants in this thread are also local VCS gurus) - and I've still had two occurrences in my professional life where I looked at the git conflict and just bailed - reading the original branch for inspiration but essentially just rewriting the change over a new and completely different system. Thankfully those were pretty early on and I think solid unit tests can really shine when it comes to trying to resolve merge conflicts. My biggest fear in rebasing/merging is that there's a function "doStuff(foo, bar, baz)" which still presents the same function signature but which had its effective code contract completely wrecked by some concurrent changes. Git is wonderful - but git can't do anything if it looks like everything in the files you're touching didn't change... but they secretly did change because there's a mess of interwoven logic between your file and another file.
  - hinkley 3y ago
    Yeah if someone has as many merges in their branch as they have commits, I might allocate ten minutes to trying to cherry-pick their changes out, and if that doesn't work I tell them to paraphrase their code onto a new branch. Probably about the same number of times that you have.

4 ms·

Personally I love the feeling of pushing up a PR and realizing that the branch I thought was done actually has several weeks of merge conflict resolution to do.

by munk-a 3y ago

hinkley 3y ago
I love the people standing outside my cube or saying "hey hinkley" in chat because even though I'm "good at merges" by developer standards I still have maybe a 90% success rate. And so I've either broken their shit, or they broke someone else's and they know I'm the closest we have to a git surgeon so they've come for a consult.
- munk-a 3y ago
  Yup ditto (and I'd assume most participants in this thread are also local VCS gurus) - and I've still had two occurrences in my professional life where I looked at the git conflict and just bailed - reading the original branch for inspiration but essentially just rewriting the change over a new and completely different system. Thankfully those were pretty early on and I think solid unit tests can really shine when it comes to trying to resolve merge conflicts. My biggest fear in rebasing/merging is that there's a function "doStuff(foo, bar, baz)" which still presents the same function signature but which had its effective code contract completely wrecked by some concurrent changes. Git is wonderful - but git can't do anything if it looks like everything in the files you're touching didn't change... but they secretly did change because there's a mess of interwoven logic between your file and another file.
  - hinkley 3y ago
    Yeah if someone has as many merges in their branch as they have commits, I might allocate ten minutes to trying to cherry-pick their changes out, and if that doesn't work I tell them to paraphrase their code onto a new branch. Probably about the same number of times that you have.