Deny nonbreaking spaces in the precommit script?
Hi,
I introduced nonbreaking spaces in Lib/os.py in a comment, because I kept Alt Gr. key pressed to write the space after # (stupid Xorg keyboard variant!).
This change introduces a strange bug in "LANG=C ./python -m test.regrtest -v test_imp test_trace" command.
The real bug was fixed in issue #10329, but I would like to know if it would be possible to block a commit introducing nonbreaking spaces? A least for me :-)
Victor
Hm, tricky, the stdlib is already supposed to be ASCII only except for author names in comments and a few specific encoding test cases. But since your non-breaking space was in a comment you'd have to add another exception to whatever checker exists.
How about fixing your personal tool chain so it displays non-breaking spaces in an obviously different way?
On Sun, Nov 7, 2010 at 7:52 AM, Victor Stinner <victor.stinner@haypocalc.com> wrote:
Hi,
I introduced nonbreaking spaces in Lib/os.py in a comment, because I kept Alt Gr. key pressed to write the space after # (stupid Xorg keyboard variant!).
This change introduces a strange bug in "LANG=C ./python -m test.regrtest -v test_imp test_trace" command.
The real bug was fixed in issue #10329, but I would like to know if it would be possible to block a commit introducing nonbreaking spaces? A least for me :-)
Victor
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- --Guido van Rossum (python.org/~guido)
2010/11/7 Victor Stinner <victor.stinner@haypocalc.com>:
Hi,
I introduced nonbreaking spaces in Lib/os.py in a comment, because I kept Alt Gr. key pressed to write the space after # (stupid Xorg keyboard variant!).
This change introduces a strange bug in "LANG=C ./python -m test.regrtest -v test_imp test_trace" command.
The real bug was fixed in issue #10329, but I would like to know if it would be possible to block a commit introducing nonbreaking spaces? A least for me :-)
I don't think add pre-commit hooks for every conceivable mistake is the right way to go.
-- Regards, Benjamin
Am 07.11.2010 19:28, schrieb Benjamin Peterson:
I would like to know if it would be possible to block a commit introducing nonbreaking spaces? A least for me :-) I don't think add pre-commit hooks for every conceivable mistake is
2010/11/7 Victor Stinner<victor.stinner@haypocalc.com>: the right way to go.
I see you're basically saying "We're all adults here" and that we should be able to control our own environment so these kinds of commits don't happen (like Guido said). Well guess what, I believe that isn't going to work. Let me tell you why.
Most* contributors work on Python in their spare time. That means they also have jobs, families, all kinds of everyday trouble. Even if 99% of the time their performance is stellar, there will be times when some stupid errors get through.
We invite more contributors now which means there are going to be more rookies than ever before. I for one am an example of that. You either expect newbies to perform like their own mentors from day one or expect mentors to waste time working out dumb rookie mistakes made because of a misconfigured environment, etc.
Speaking of environments, they change. Software evolves, people switch machines, operating systems, editors, toolchains. If one Debian veteran switches to Mac OS X and makes some error because of false assumptions, misconfigured software, whatever... his experience should prevent other people from making the same mistake in the future.
I could go on and risk boring you to death. The point is, if we can automate stuff out of the workflow, we should definitely do it. Each and every time. We don't gain anything by not implementing automation.
Even if that commit hook prevents a single wrong commit a year, it's worth it. As unpaid volunteers, we don't have time for hunting the same mistakes twice.
One last disclaimer. I'm not a native speaker so if the tone of my post sounds offensive or rude, I apologise in advance because that was not my intention. OTOH, the zen says explicit is better than diplomatic. Or something like that.
- Yup, that's guessing. Correct me if I'm wrong.
-- Best regards, Łukasz Langa
2010/11/8 Łukasz Langa <lukasz@langa.pl>:
I see you're basically saying "We're all adults here" and that we should be able to control our own environment so these kinds of commits don't happen (like Guido said). Well guess what, I believe that isn't going to work. Let me tell you why.
I must say I kind of agree with Łukasz.
One of the reasons I use Python is because it alleviates my having to think about memory management and checking for error values. In the same fashion, having automated checks means I can spend less of my time thinking about possible stupid mistakes, and less time fixing them.
Cheers,
Dirkjan
On Mon, Nov 08, 2010 at 11:55:39AM +0100, Łukasz Langa wrote:
Even if that commit hook prevents a single wrong commit a year, it's worth it. As unpaid volunteers, we don't have time for hunting the same mistakes twice.
For common mistakes, there are commit hooks which prevent you from committing wrongly indented code or rst files. This helps couple of times a year, but having commit-hooks for every other mistake may not be a good idea.
We can just customize our environments. It is easy.
-- Senthil
On 08/11/2010 11:42, Senthil Kumaran wrote:
On Mon, Nov 08, 2010 at 11:55:39AM +0100, Łukasz Langa wrote:
Even if that commit hook prevents a single wrong commit a year, it's worth it. As unpaid volunteers, we don't have time for hunting the same mistakes twice. For common mistakes, there are commit hooks which prevent you from committing wrongly indented code or rst files. This helps couple of times a year, but having commit-hooks for every other mistake may not be a good idea.
We can just customize our environments. It is easy. Additional checks could be put in
make patchcheckor a local commit hook for hg.
All the best,
Michael Foord
--
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Am 08.11.2010 12:55, schrieb Michael Foord:
On 08/11/2010 11:42, Senthil Kumaran wrote:
We can just customize our environments. It is easy.
I already pointed out in my last post why that's not going to solve the problem.
Additional checks could be put in
make patchcheckor a local commit hook for hg.
Automation always pays off. Simplifying the process always pays off. Providing yet another step to the workflow would be a move in the opposite direction*. Is there any point in weighing each time whether a mistake is common enough to be included in the commit hooks? It's not like we're paying some SVN vendor a fee per hook ;-)
- A completely separate topic would be that programmer-side precommit hooks are a terrific idea for Hg. But just as client-side form validation doesn't free Web apps from having to implement server-side as well, I believe hooks on the central repository should be as complete and as restrictive as it gets.
-- Best regards, Łukasz Langa
On 08/11/2010 12:18, Łukasz Langa wrote:
Am 08.11.2010 12:55, schrieb Michael Foord:
On 08/11/2010 11:42, Senthil Kumaran wrote:
We can just customize our environments. It is easy.
I already pointed out in my last post why that's not going to solve the problem.
Additional checks could be put in
make patchcheckor a local commit hook for hg.Automation always pays off. Simplifying the process always pays off. Providing yet another step to the workflow would be a move in the opposite direction*.
You mean make patchcheck isn't *already* part of your workflow?
Michael
Is there any point in weighing each time whether a mistake is common enough to be included in the commit hooks? It's not like we're paying some SVN vendor a fee per hook ;-)
- A completely separate topic would be that programmer-side precommit hooks are a terrific idea for Hg. But just as client-side form validation doesn't free Web apps from having to implement server-side as well, I believe hooks on the central repository should be as complete and as restrictive as it gets.
--
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, 2010-11-08 at 12:22 +0000, Michael Foord wrote:
On 08/11/2010 12:18, Łukasz Langa wrote:
Am 08.11.2010 12:55, schrieb Michael Foord:
On 08/11/2010 11:42, Senthil Kumaran wrote:
We can just customize our environments. It is easy.
I already pointed out in my last post why that's not going to solve the problem.
Additional checks could be put in
make patchcheckor a local commit hook for hg.Automation always pays off. Simplifying the process always pays off. Providing yet another step to the workflow would be a move in the opposite direction*.
You mean
make patchcheckisn't *already* part of your workflow?
FWIW, "make patchcheck" isn't mentioned on the "Python Patch Submission Guidelines" here: http://www.python.org/dev/patches/ and doesn't seem to be mentioned anywhere on the website.
I'm attaching a patch (to the website) that adds this to that page.
(snip)
On 08/11/2010 17:28, David Malcolm wrote:
On Mon, 2010-11-08 at 12:22 +0000, Michael Foord wrote:
On 08/11/2010 12:18, Łukasz Langa wrote:
On 08/11/2010 11:42, Senthil Kumaran wrote:
We can just customize our environments. It is easy. I already pointed out in my last post why that's not going to solve
Am 08.11.2010 12:55, schrieb Michael Foord: the problem.
Additional checks could be put in
make patchcheckor a local commit hook for hg. Automation always pays off. Simplifying the process always pays off. Providing yet another step to the workflow would be a move in the opposite direction*. You meanmake patchcheckisn't *already* part of your workflow? FWIW, "make patchcheck" isn't mentioned on the "Python Patch Submission Guidelines" here: http://www.python.org/dev/patches/ and doesn't seem to be mentioned anywhere on the website.I'm attaching a patch (to the website) that adds this to that page.
(snip) I've forwarded the patch to the pydotorg-www mailing list. Thanks.
All the best,
Michael Foord
--
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Automation always pays off. Simplifying the process always pays off. Providing yet another step to the workflow would be a move in the opposite direction*. Is there any point in weighing each time whether a mistake is common enough to be included in the commit hooks? It's not like we're paying some SVN vendor a fee per hook ;-)
No, but it's not like the hooks appear by telepathy either. Someone has to write them and to maintain them. I'm not sure who that is currently (Martin is a safe guess ;-)) but, regardless, it's not "free" in terms of maintenance overhead.
I personally don't care whether we deny non-breaking spaces or not. I see no reason to deny them, since the cause of the test_trace failure was ultimately a bug in the trace module, and the non-breaking space actually uncovered this bug (isn't uncovering bugs a good thing?). The interpreter has no problem with utf-8 characters in source files, and I guess most humans have no problems reading non-breaking spaces either.
Regards
Antoine.
On Mon, Nov 8, 2010 at 10:33 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I personally don't care whether we deny non-breaking spaces or not. I see no reason to deny them, since the cause of the test_trace failure was ultimately a bug in the trace module, and the non-breaking space actually uncovered this bug (isn't uncovering bugs a good thing?). The interpreter has no problem with utf-8 characters in source files, and I guess most humans have no problems reading non-breaking spaces either.
Indeed, the problem with automating this particular test is that it is ill-specified. Assuming we decided to change reindent.py (or added some other checker) to reject unexpected characters:
- what characters are disallowed?
- are those characters also disallowed in string literals?
- what about source files that are specifically designed to test handling of those characters in particular contexts?
Non-breaking spaces are legal in utf-8 encoded Python source files. While including them accidentally is less than ideal, it is perfectly valid to include them deliberately. Trying to design an automated check that can make a reasonable guess at intent is going to require far more effort than is needed.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Nov 8, 2010 at 10:53 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Non-breaking spaces are legal in utf-8 encoded Python source files. While including them accidentally is less than ideal, it is perfectly valid to include them deliberately. Trying to design an automated check that can make a reasonable guess at intent is going to require far more effort than is needed.
s/needed/reasonable/
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 08/11/2010 12:53, Nick Coghlan wrote:
[snip...] Non-breaking spaces are legal in utf-8 encoded Python source files. While including them accidentally is less than ideal, it is perfectly valid to include them deliberately. Trying to design an automated check that can make a reasonable guess at intent is going to require far more effort than is needed.
Is it valid though? Standard library rules are ascii only (as referenced by Guido in this thread). If you need the characters in a string literal you must escape them.
Michael
Cheers, Nick.
--
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord <michael@voidspace.org.uk> wrote:
On 08/11/2010 12:53, Nick Coghlan wrote:
[snip...] Non-breaking spaces are legal in utf-8 encoded Python source files. While including them accidentally is less than ideal, it is perfectly valid to include them deliberately. Trying to design an automated check that can make a reasonable guess at intent is going to require far more effort than is needed.
Is it valid though? Standard library rules are ascii only (as referenced by Guido in this thread). If you need the characters in a string literal you must escape them.
Nope - those are the "few specific encoding test cases" he mentioned in that email. They take advantage of the utf-8 encoding of the source files these days.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 08/11/2010 12:59, Nick Coghlan wrote:
On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord<michael@voidspace.org.uk> wrote:
On 08/11/2010 12:53, Nick Coghlan wrote:
[snip...] Non-breaking spaces are legal in utf-8 encoded Python source files. While including them accidentally is less than ideal, it is perfectly valid to include them deliberately. Trying to design an automated check that can make a reasonable guess at intent is going to require far more effort than is needed.
Is it valid though? Standard library rules are ascii only (as referenced by Guido in this thread). If you need the characters in a string literal you must escape them. Nope - those are the "few specific encoding test cases" he mentioned in that email. They take advantage of the utf-8 encoding of the source files these days.
Ah, well - if we *do* allow non-ascii characters in standard library files then we *can't* make it a pre-commit hook unless we hardcode those exceptions into it.
Adding a pre-commit hook would necessitate someone creating it anyway, and so far no-one has volunteered.
All the best,
Michael
Cheers, Nick.
--
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, Nov 8, 2010 at 1:59 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord <michael@voidspace.org.uk> wrote:
On 08/11/2010 12:53, Nick Coghlan wrote:
[snip...] Non-breaking spaces are legal in utf-8 encoded Python source files. While including them accidentally is less than ideal, it is perfectly valid to include them deliberately. Trying to design an automated check that can make a reasonable guess at intent is going to require far more effort than is needed.
Is it valid though? Standard library rules are ascii only (as referenced by Guido in this thread). If you need the characters in a string literal you must escape them.
Nope - those are the "few specific encoding test cases" he mentioned in that email. They take advantage of the utf-8 encoding of the source files these days.
One would have thought that "test cases" referred to test cases, not strings in non-test code, and that the "the stdlib is already supposed to be ASCII only" meant that the standard library is supposed to be ASCII only, not UTF-8.
</F>
Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
One would have thought that "test cases" referred to test cases, not strings in non-test code, and that the "the stdlib is already supposed to be ASCII only" meant that the standard library is supposed to be ASCII only, not UTF-8.
“[...] the stdlib is already supposed to be ASCII only except for author names in comments and a few specific encoding test cases.”
You seem to have missed part of the sentence.
On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
One would have thought that "test cases" referred to test cases, not strings in non-test code, and that the "the stdlib is already supposed to be ASCII only" meant that the standard library is supposed to be ASCII only, not UTF-8.
“[...] the stdlib is already supposed to be ASCII only except for author names in comments and a few specific encoding test cases.”
You seem to have missed part of the sentence.
No, I didn't. Try again.
</F>
Am 08.11.2010 14:19, schrieb Fredrik Lundh:
On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
One would have thought that "test cases" referred to test cases, not strings in non-test code, and that the "the stdlib is already supposed to be ASCII only" meant that the standard library is supposed to be ASCII only, not UTF-8.
“[...] the stdlib is already supposed to be ASCII only except for author names in comments and a few specific encoding test cases.”
You seem to have missed part of the sentence.
No, I didn't. Try again.
Ok, my try: You deliberately have chosen to ignore it. Right?
If it's not that, I can't guess what you may have meant.
Regards, Martin
On Mon, Nov 8, 2010 at 11:03 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Am 08.11.2010 14:19, schrieb Fredrik Lundh:
On Mon, Nov 8, 2010 at 2:17 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le lundi 08 novembre 2010 à 14:10 +0100, Fredrik Lundh a écrit :
One would have thought that "test cases" referred to test cases, not strings in non-test code, and that the "the stdlib is already supposed to be ASCII only" meant that the standard library is supposed to be ASCII only, not UTF-8.
“[...] the stdlib is already supposed to be ASCII only except for author names in comments and a few specific encoding test cases.”
You seem to have missed part of the sentence.
No, I didn't. Try again.
Ok, my try: You deliberately have chosen to ignore it. Right?
Not at all. The original statement had the form "A, except B and C". That's not very hard to parse, is it? A is always true, except for the specific cases B and C.
When Michael then infers that "A means that D must be escaped", Nick claims that C ("encoding test cases") actually was referring to D ("string literals in the standard library"). That's clearly not true for any straight-forward interpretation of those phrases, and I've never ever seen Guido be that imprecise in his writing, but when I wonder why he said C if he meant D, I suddenly find myself in a fight with two minibosses. What's going on here?
</F>
2010/11/8 Senthil Kumaran <orsenthil@gmail.com>:
On Mon, Nov 08, 2010 at 11:55:39AM +0100, Łukasz Langa wrote:
Even if that commit hook prevents a single wrong commit a year, it's worth it. As unpaid volunteers, we don't have time for hunting the same mistakes twice.
For common mistakes, there are commit hooks which prevent you from committing wrongly indented code or rst files. This helps couple of times a year, but having commit-hooks for every other mistake may not be a good idea.
Depends on how you phrase the tests, though -- the tests "does this file only contain characters from the accepted character set" and "does this file contain a non-breaking space" will both catch this issue, but the former is more useful.
</F>
2010/11/8 Łukasz Langa <lukasz@langa.pl>:
Am 07.11.2010 19:28, schrieb Benjamin Peterson:
2010/11/7 Victor Stinner<victor.stinner@haypocalc.com>:
I would like to know if it would be possible to block a commit introducing nonbreaking spaces? A least for me :-)
I don't think add pre-commit hooks for every conceivable mistake is the right way to go.
I see you're basically saying "We're all adults here" and that we should be able to control our own environment so these kinds of commits don't happen (like Guido said). Well guess what, I believe that isn't going to work. Let me tell you why.
Most* contributors work on Python in their spare time. That means they also have jobs, families, all kinds of everyday trouble. Even if 99% of the time their performance is stellar, there will be times when some stupid errors get through.
We invite more contributors now which means there are going to be more rookies than ever before. I for one am an example of that. You either expect newbies to perform like their own mentors from day one or expect mentors to waste time working out dumb rookie mistakes made because of a misconfigured environment, etc.
Speaking of environments, they change. Software evolves, people switch machines, operating systems, editors, toolchains. If one Debian veteran switches to Mac OS X and makes some error because of false assumptions, misconfigured software, whatever... his experience should prevent other people from making the same mistake in the future.
I could go on and risk boring you to death. The point is, if we can automate stuff out of the workflow, we should definitely do it. Each and every time. We don't gain anything by not implementing automation.
I don't think you can ever automate "checking for mistakes" out of the workflow. There will never be a commit hook that checks whether you created a race condition or deference possibly uninitialized memory. IMO, if you're unwilling to be looking for simple and complex bugs, you should think twice before committing at all.
Even if that commit hook prevents a single wrong commit a year, it's worth it. As unpaid volunteers, we don't have time for hunting the same mistakes twice.
One last disclaimer. I'm not a native speaker so if the tone of my post sounds offensive or rude, I apologise in advance because that was not my intention. OTOH, the zen says explicit is better than diplomatic. Or something like that.
-- Regards, Benjamin
Am 08.11.2010 15:04, schrieb Benjamin Peterson:
I don't think you can ever automate "checking for mistakes" out of the workflow. There will never be a commit hook that checks whether you created a race condition or deference possibly uninitialized memory.
That goes without saying. Then again, with my post I was aiming at the subset of problems that can be caught automatically. You seem to be saying that spell checkers are useless because they don't guarantee that sentences make actual sense.
IMO, if you're unwilling to be looking for simple and complex bugs, you should think twice before committing at all.
Ouch. I am unwilling to accuse anybody of unwillingness ;-) It's obvious that every committer is obliged to do her best to ensure quality of each and every commit. This doesn't mean automated checks are unnecessary. Nor does that mean people advocating for more safety catches look for ways for being sloppy.
Then again this discussion is already far too long for such a simple matter. So, to make matters a bit more productive:
I am willing to convert existing SVN hooks to Mercurial and maintain them, if there's nobody doing that already.
-- Best regards, Łukasz Langa
Am 08.11.2010 15:30, schrieb Łukasz Langa:
Am 08.11.2010 15:04, schrieb Benjamin Peterson:
I don't think you can ever automate "checking for mistakes" out of the workflow. There will never be a commit hook that checks whether you created a race condition or deference possibly uninitialized memory.
That goes without saying. Then again, with my post I was aiming at the subset of problems that can be caught automatically. You seem to be saying that spell checkers are useless because they don't guarantee that sentences make actual sense.
After the hg migration, I can only recommend my hgcodesmell extension that takes care of checking for (at the moment) debugging leftovers or merge conflict markers, but can easily be adapted to check for whatever you fear will destroy your reputation as a committer...
http://bitbucket.org/birkenfeld/hgcodesmell/
It doesn't simply deny the commit, but rather gives you a diff of the questionable change and asks whether to continue.
IMO, if you're unwilling to be looking for simple and complex bugs, you should think twice before committing at all.
Ouch. I am unwilling to accuse anybody of unwillingness ;-) It's obvious that every committer is obliged to do her best to ensure quality of each and every commit. This doesn't mean automated checks are unnecessary. Nor does that mean people advocating for more safety catches look for ways for being sloppy.
Then again this discussion is already far too long for such a simple matter. So, to make matters a bit more productive:
I am willing to convert existing SVN hooks to Mercurial and maintain them, if there's nobody doing that already.
That's already done; the whitespace checking hook we have for SVN currently is ported and in the hg.python.org/hooks repo.
Georg
participants (13)
-
"Martin v. Löwis" -
Antoine Pitrou -
Benjamin Peterson -
David Malcolm -
Dirkjan Ochtman -
Fredrik Lundh -
Georg Brandl -
Guido van Rossum -
Michael Foord -
Nick Coghlan -
Senthil Kumaran -
Victor Stinner -
Łukasz Langa