4 ms·

My read of the article implies that they were running the new method on the side, and comparing the results to the old method that was still running in producti

by nod 11y ago

My read of the article implies that they were running the new method on the side, and comparing the results to the old method that was still running in production. They got to 100% before they actually pulled the lever on what customers would use. Edit: Ah, I see - talking about the Git bugs, not the differences . I’m actually not surprised that “256 (or a multiple) merge conflicts” was never noticed (or at least root-caused and fixed) by the entire git community. Wonderful ability to use a large userbase as a giant fuzzer.

pilif 11y ago
I think OP was talking about the issue in git itself that caused merges with mod 256 conflicts to go though and be committed, including all the merge error markers. This happened on their live system (and would have happened on the command line for local git users), so OP (and incidentally, me too) was wondering how that wasn't noticed and wasn't causing support issues (it probably was which might have been another reason for this refactoring)
- peff 11y ago
  I think it is a combination of two things: - the mod-256 conflict bug is exceedingly rare. Keep in mind that this is mod-256 individual hunk conflicts in a _single file_. Most files in a merge with conflicts have a handful of hunks. Over all of the testing at GitHub, only a single merge triggered this bug, and it was on a long repetitive file with automated changes. - the failure case was to quietly accept the merge. The result was obviously bogus, but didn't look any different than a user accidentally checking in the merge conflict markers. So if it was happening, I'd suspect that it went undiscovered either because the merge results were never used (e.g., it was a test-merge to feed the PR "Merge" button status) or the users simply scratched their head and fixed it.
mordocai 11y ago
I would guess abritishguy was talking about the two git command line bugs they found.

by nod 11y ago

pilif 11y ago

I think OP was talking about the issue in git itself that caused merges with mod 256 conflicts to go though and be committed, including all the merge error markers. This happened on their live system (and would have happened on the command line for local git users), so OP (and incidentally, me too) was wondering how that wasn't noticed and wasn't causing support issues (it probably was which might have been another reason for this refactoring)

peff 11y ago
I think it is a combination of two things: - the mod-256 conflict bug is exceedingly rare. Keep in mind that this is mod-256 individual hunk conflicts in a _single file_. Most files in a merge with conflicts have a handful of hunks. Over all of the testing at GitHub, only a single merge triggered this bug, and it was on a long repetitive file with automated changes. - the failure case was to quietly accept the merge. The result was obviously bogus, but didn't look any different than a user accidentally checking in the merge conflict markers. So if it was happening, I'd suspect that it went undiscovered either because the merge results were never used (e.g., it was a test-merge to feed the PR "Merge" button status) or the users simply scratched their head and fixed it.

mordocai 11y ago

I would guess abritishguy was talking about the two git command line bugs they found.