I think one area where a broad search could be helpful is narrowing down when this first started happening, and narrowing down which deployment must have been the issue. Since we're on a biweekly cycle, it shouldn't be a huge amount of code that contributes to this bug. For example, someone with enough git-fu and having read the bug carefully enough might be able to point to a likely culprit revision.
I am going to hijack this thread -- hence the change in subject -- since this is related to the other thread I started about git commit history.
If this is a newly introduced bug (which seems to be the case from what I can gather from this email), then git bisect would have been the ideal way to nail the culprit commit. git bisect basically lets you binary search your way to a bad commit starting from a known good commit and a known bad commit. It is an absolutely awesome tool that git gives you. I have used this more than once on other projects to nail a bug.
But, git bisect will work best with a linear commit history, and it is not going to really work well with the current totally non-linear commit history on core. So, one very good reason to examine how to minimize merge commits with gerrit.
That said, with some patience, git bisect might still be a useful thing to try.
Subbu. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
