On Tue, Aug 19, 2008 at 12:39 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Scott Chacon" <schacon@xxxxxxxxx> writes: > >> If the patch is acceptable, I will update the githooks doc with more >> information, but we would like this so that you could add a hook that >> runs your automated tests before a push would go through. > > I've said this number of times on this list but I guess it has been while > since the last time I said it. > > "If the patch is acceptable, I'll document it" is the last thing we as > reviewers would want to hear from the submitter, *unless* there is an > ongoing discussion that already have established what is wanted and a > patch came as "ok, here is a possible solution, what do you guys think?". > > If the original submitter does not care enough to defend why it is needed, > why should reviewers spend their precious brain cycles to decipher what it > does, guess what situation the change would help, and determine if the > change actually would help the situation it might be trying to help (and > risk wasting all this work because they guessed the motivation wrong)? > And what assurance would we have that the change will be maintained and > supported? I didn't say, "if it's acceptable, I'll document it", I said I would add more information into the githooks doc. I updated the git-push.txt doc and explained what it did with the commit message and sent test cases. There should have been more than enough information on what it did in the message. Then I sent a patch to githooks with use cases like 5 minutes later. I'm more than happy to defend it and replied to Jeffs email almost immediately. > Having said that, I would agree "validate and potentially stop before > pushing" is a very good thing to have. > > It is still unclear at this point what kind of input that validation would > want to base its decision on. At least we would want what branch is being > pushed (so that a validation failure on a branch that is not being pushed > would not interfere), and possibly where you are pushing to (so that you > can still push a change you would want to verify and potentially polish on > a different test/dev box without getting interfered). I would be happy to add the name of the branch being updated and the remote we're trying to push to. Is there interest then, in the patch? Should I spend my precious brain cycles on adding that functionality? Scott -- 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
