On 11/26/2012 10:41 PM, Eric S. Raymond wrote:
The next things on my git to-do list are
[...]
2. Submit a doc patch containing guidelines that (a) Python scripts should
check for their floor version and error out gracefully if they won't
run with the host's interpreter, and (b) Python
Michael Haggerty mhag...@alum.mit.edu:
OK, now let's discuss *which* minimum Python version that git should
support in the hypothetical new world...
By all means!
It would be a shame to leave RHEL 5 users behind if Python is used to
implement important git functionality. Python 2.4 is
Eric S. Raymond e...@thyrsus.com writes:
I agree that 2.4 is still quite OK. I'm a little concerned that dropping that
far back might store up some transition problems for the day we decide to
make the jump to Python 3.
On the other hand, I think gating features on RHEL5 might be
Junio C Hamano gits...@pobox.com:
I won't worry about Python 3 yet; in what timeframe did Python's
i18n/unicode support become usable? In 2.4, or 2.6?
Er, it depends on what you consider usable.
Unicode integration turned out to have a lot messier edge cases than
anyone understood going in.
Junio C Hamano gits...@pobox.com:
I'll reword the title (readers of git log output 6 months down the
road will not care if this is the third try or the first one) and
tweak things here and there before queuing.
Result looks good from here.
The next things on my git to-do list are
1. Audit
e...@thyrsus.com (Eric S. Raymond) writes:
@@ -0,0 +1,91 @@
+= Integrating new subcommands =
+
+This is how-to documentation for people who want to add extension
+commands to git. It should be read alongside api-builtin.txt.
+
+== Runtime environment ==
+
+git subcommands are standalone
Junio C Hamano gits...@pobox.com:
Even though ={n} title ={n} is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.
Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
Noted for
7 matches
Mail list logo