Hacker News Reader

Comment by abritishguy | Hacker News Reader

Wow, strange that people weren't reporting these merge issues when they were clearly impacting people.

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.

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)

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.

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

I haven't read the whole article yet, so I might have missed something; but how do we know that people weren't reporting these issues?

I've always had to report issues to GitHub via email as they do not have a public issue tracker (something I've always found a bit ironic).

It's interesting that git is the same. [EDIT:] ...in that all issues and PRs are emailed rather than entered into a web app.

git remains the same, indeed :)

I'm not familiar with the Git project's inner workings, but their website git-scm.com tells me they are hosted on GitHub, which has a public issue tracker: https://github.com/git/git-scm.com/issues

GitHub, however, only allows issues to be reported via private mail. I'm not aware of a 'public' issue tracker for GitHub anywhere (even if a mailing list).

This is the web application for the git-scm.com site. It is meant to be the first place a person new to Git will land and download or learn about the Git SCM system.

This app is written in Ruby on Rails and deployed on Heroku.

Reply on news.ycombinator.com