On Fri, May 13, 2016 at 12:46:57PM -0700, Junio C Hamano wrote: > > We don't want commits that fail the test suite, since it makes bisection > > more difficult. But you can mark known bugs like: > > > > test_expect_failure 'git-foo should output bar' ' > > ... > > ' > > > > I think it's OK to submit a patch like that. Hopefully somebody picks > > that up and combines it with their fix patch, but if not, then it at > > least documents the failure for later generations. > > ... but we do not want to overdo this. > > An expect_failure helps when somebody is actually starting to work > on a breakage by setting a goal, but otherwise nobody would look at > them. I do not think we know if 120+ instances of expect_failure in > t/ we already have are still all valid; some of them even might be > requesting a behaviour that we decided is a wrong expectation later. True. I almost wrote more on this, but held back. But since you seem interested... :) I think that it's a really nice thing to write up your test as test_expect_failure and post it to the list as a patch that is ready to be applied, _even if we don't apply it_. Because that format makes it super-easy for somebody who does want to work on it to just "git am" your patch and focus on fixing it. And your patch can either go at the front of their series, or they can squash it in and acknowledge you in the commit message. But either way it reduces the amount of work they have to do (whether they work on the bug soon, or much later). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html