* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Duy Nguyen @ 2013-01-19 5:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
On Sat, Jan 19, 2013 at 7:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in the changes under
> review). As long as these narrow audiences have a way to learn the
> names of refs or objects pointed at by the refs out-of-band, it is
> not necessary to advertise these refs.
>
> On the server end, you tell upload-pack that some refs do not have
> to be advertised with the uploadPack.hiderefs multi-valued
> configuration variable:
>
> [uploadPack]
> hiderefs = refs/changes
>
> The changes necessary on the client side to allow fetching objects
> at the tip of a ref in hidden hierarchies are much more involved and
> not part of this early preview, but the end user UI is expected to
> be like these:
>
> $ git fetch $there refs/changes/72/41672/1
> $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
>
> That is, you ask for a refname as usual even though it is not part
> of ls-remote response, or you ask for the commit object that is at
> the tip of whatever hidden ref you are interested in.
Should the client side learn how to list hidden refs too? I'm thinking
of an extreme case where upload-pack advertises nothing (or maybe just
refs/heads/master) and it's up to the client to ask for the ref
selection it's interested in. upload-pack may need more updates to do
that, I think.
--
Duy
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: Techlive Zheng @ 2013-01-19 5:48 UTC (permalink / raw)
To: Herman van Rink; +Cc: Yann Dirson, git list
In-Reply-To: <5082FE13.2000003@initfour.nl>
On 12-10-20, Herman van Rink wrote:
> On 10/19/2012 03:21 PM, Yann Dirson wrote:
> > As the examples in git-subtree.txt show, the synopsis in the same file should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P <prefix> <commit>
> > +'git subtree' add -P <prefix> <repository> <commit>
> >
> > Failure to specify the repository (by just specifying a local commit) fails with
> > the cryptic:
> >
> > warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> > fatal: just how do you expect me to merge 0 trees?
> >
> >
> > Furthermore, the doc paragraph for add, aside from mentionning <repository>, also
> > mentions a <refspec> which the synopsis does not show either.
> >
> >
> > As a sidenote it someone wants to do some maintainance, using "." as repository when
> > the branch to subtree-add is already locally available does not work well either
> > (fails with "could not find ref myremote/myhead").
> >
>
> The version of subtree in contrib is rather out-dated unfortunately.
You should really submit these patches here for reviewing, David is
actively maintaining this tool here.
>
> I've collected a bunch of patches in
> https://github.com/helmo/git/tree/subtree-updates
>
> The documentation issue is also fixed in there.
>
> --
>
> Met vriendelijke groet / Regards,
>
> Herman van Rink
> Initfour websolutions
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: t9902 fails
From: Torsten Bögershausen @ 2013-01-19 5:38 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Junio C Hamano, Jonathan Nieder, Torsten Bögershausen,
Jeff King, git, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <201301182323.55378.avila.jn@gmail.com>
On 18.01.13 23:23, Jean-Noël AVILA wrote:
> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano <gitster@pobox.com> writes:
>>> How about doing something like this and set that variable in the
>>> test instead? If STD_ONLY is not set, you will get everything, but
>>> when STD_ONLY is set, we will stop reading from "help -a" when it
>>> starts listing additional stuff.
>
> I tried both of your propositions but none made test 10 of t9902 pass.
>
> Am I supposed to run "make install" before running the test?
No. The test suite could (and should) be run before you make install.
So a typical sequence could be:
Run test suite, and if that passes, install the binaries on my system.
This could look like this on the command line:
make test && sudo make install
Jean-Noël,
would it be possible to run
"git status"
and share the result with us?
And did you try Jonathans patch?
/Torsten
^ permalink raw reply
* [PATCH 2/2] upload-pack: allow hiding ref hiearchies
From: Junio C Hamano @ 2013-01-19 0:37 UTC (permalink / raw)
To: git; +Cc: spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
Teach upload-pack to omit some refs from the initial advertisement
by introducing the uploadPack.hiderefs multivalued configuration
variable. Any ref that is under the hierarchies listed on the value
of this variable is excluded from responses to "ls-remote", "fetch"
or "clone" requests. One typical use case may be
[uploadPack]
hiderefs = refs/changes
Note that the underlying protocol allows a request to fetch objects
at the tip of any ref, including the hidden ones, but on the client
side (e.g. fetch-pack), the requests are checked against the
ls-remote response, so it cannot ask for refs/changes/72/41672/1, or
for the object name (which is what eventually goes over the wire on
"want" line) the user may obtain out of band (e.g. Gerrit
dashboard). A new capability "allow-tip-sha1-in-want" is returned
by upload-pack to signal updated clients that it may be OK to ask
for objects that were not advertised.
If we want to allow fetching refname that is hidden, e.g.
$ git fetch $there refs/changes/72/41672/1
we need to further update the server side to understand a message
that has the refname instead of object name on "want" line. The
necessary change to the server side to support that is not in this
step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t5512-ls-remote.sh | 9 ++++++++
upload-pack.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index d16e5d3..9ee3d2a 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -126,4 +126,13 @@ test_expect_success 'Report match with --exit-code' '
test_cmp expect actual
'
+test_expect_success 'Hide some refs' '
+ test_config uploadPack.hiderefs refs/tags &&
+ git ls-remote . >actual &&
+ test_unconfig uploadPack.hiderefs &&
+ git ls-remote . |
+ sed -e "/ refs\/tags\//d" >expect &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 3dd220d..54c304d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -12,6 +12,7 @@
#include "run-command.h"
#include "sigchain.h"
#include "version.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<n>] <dir>";
@@ -28,10 +29,13 @@ static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<
static unsigned long oldest_have;
-static int multi_ack, nr_our_refs;
+static int multi_ack;
+static int nr_our_refs; /* This counts both advertised and unadvertised */
static int no_done;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
+static struct string_list *hide_refs;
+static int allow_tip_sha1_in_want;
static int shallow_nr;
static struct object_array have_obj;
static struct object_array want_obj;
@@ -722,6 +726,23 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int ref_is_hidden(const char *refname)
+{
+ struct string_list_item *item;
+
+ if (!hide_refs)
+ return 0;
+ for_each_string_list_item(item, hide_refs) {
+ int len;
+ if (prefixcmp(refname, item->string))
+ continue;
+ len = strlen(item->string);
+ if (!refname[len] || refname[len] == '/')
+ return 1;
+ }
+ return 0;
+}
+
static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
struct object *o = lookup_unknown_object(sha1);
@@ -743,11 +764,14 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
unsigned char peeled[20];
mark_our_ref(refname, sha1, flag, cb_data);
+ if (allow_tip_sha1_in_want && ref_is_hidden(refname))
+ return 0;
if (capabilities)
- packet_write(1, "%s %s%c%s%s agent=%s\n",
+ packet_write(1, "%s %s%c%s%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
0, capabilities,
+ allow_tip_sha1_in_want ? " allow-tip-sha1-in-want" : "",
stateless_rpc ? " no-done" : "",
git_user_agent_sanitized());
else
@@ -758,11 +782,21 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static int check_hidden_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ if (!ref_is_hidden(refname))
+ return 0;
+ allow_tip_sha1_in_want = 1;
+ return 1; /* terminate iteration over refs early */
+}
+
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
reset_timeout();
head_ref_namespaced(send_ref, NULL);
+ if (hide_refs)
+ for_each_namespaced_ref(check_hidden_ref, NULL);
for_each_namespaced_ref(send_ref, NULL);
packet_flush(1);
} else {
@@ -779,6 +813,28 @@ static void upload_pack(void)
}
}
+static int upload_pack_config(const char *var, const char *value, void *unused)
+{
+ if (!strcmp("uploadpack.hiderefs", var)) {
+ char *ref;
+ int len;
+
+ if (!value)
+ return config_error_nonbool(var);
+ ref = xstrdup(value);
+ len = strlen(ref);
+ while (len && ref[len - 1] == '/')
+ ref[--len] = '\0';
+ if (!hide_refs) {
+ hide_refs = xcalloc(1, sizeof(*hide_refs));
+ hide_refs->strdup_strings = 1;
+ }
+ string_list_append(hide_refs, ref);
+ return 0;
+ }
+ return 0;
+}
+
int main(int argc, char **argv)
{
char *dir;
@@ -830,6 +886,7 @@ int main(int argc, char **argv)
die("'%s' does not appear to be a git repository", dir);
if (is_repository_shallow())
die("attempt to fetch/clone from a shallow repository");
+ git_config(upload_pack_config, NULL);
if (getenv("GIT_DEBUG_SEND_PACK"))
debug_fd = atoi(getenv("GIT_DEBUG_SEND_PACK"));
upload_pack();
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* [PATCH 1/2] upload-pack: share more code
From: Junio C Hamano @ 2013-01-19 0:37 UTC (permalink / raw)
To: git; +Cc: spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
We mark the objects pointed at our refs with "OUR_REF" flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
just like we did in 435c833 (upload-pack: use peel_ref for ref
advertisements, 2012-10-04).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
upload-pack.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..3dd220d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,28 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct object *o = lookup_unknown_object(sha1);
+ if (!o)
+ die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+ if (!(o->flags & OUR_REF)) {
+ o->flags |= OUR_REF;
+ nr_our_refs++;
+ }
+ return 0;
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
" include-tag multi_ack_detailed";
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, "%s %s%c%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
@@ -740,27 +753,11 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, "%s %s^{}\n", sha1_to_hex(peeled), refname_nons);
return 0;
}
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
-{
- struct object *o = parse_object(sha1);
- if (!o)
- die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
- return 0;
-}
-
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-19 0:37 UTC (permalink / raw)
To: git; +Cc: spearce, mfick
This is an early preview of reducing the network cost while talking
with a repository with tons of refs, most of which are of use by
very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
useful only for people who are interested in the changes under
review). As long as these narrow audiences have a way to learn the
names of refs or objects pointed at by the refs out-of-band, it is
not necessary to advertise these refs.
On the server end, you tell upload-pack that some refs do not have
to be advertised with the uploadPack.hiderefs multi-valued
configuration variable:
[uploadPack]
hiderefs = refs/changes
The changes necessary on the client side to allow fetching objects
at the tip of a ref in hidden hierarchies are much more involved and
not part of this early preview, but the end user UI is expected to
be like these:
$ git fetch $there refs/changes/72/41672/1
$ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
That is, you ask for a refname as usual even though it is not part
of ls-remote response, or you ask for the commit object that is at
the tip of whatever hidden ref you are interested in.
Junio C Hamano (2):
upload-pack: share more code
upload-pack: allow hiding ref hiearchies
t/t5512-ls-remote.sh | 9 ++++++
upload-pack.c | 86 ++++++++++++++++++++++++++++++++++++++++++----------
2 files changed, 79 insertions(+), 16 deletions(-)
--
1.8.1.1.454.g48d39c0
^ permalink raw reply
* Re: [PATCH] git-svn: teach find-rev to find near matches
From: Junio C Hamano @ 2013-01-18 23:14 UTC (permalink / raw)
To: Eric Wong; +Cc: John Keeping, git
In-Reply-To: <20130118004917.GA27106@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I've pushed this out to git://bogomips.org/git-svn along with a few
> other things I seem to have forgotten about :x
>
> John Keeping (1):
> git-svn: teach find-rev to find near matches
>
> Jonathan Nieder (2):
> Git::SVN::Editor::T: pass $deletions to ->A and ->D
> git svn: do not overescape URLs (fallback case)
Thanks; pulled and pushed out.
^ permalink raw reply
* Re: [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement
From: Junio C Hamano @ 2013-01-18 23:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, git-dev
In-Reply-To: <20120106191740.GA12903@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> When we advertise a ref, the first thing we do is parse the
> pointed-to object. This gives us two things:
>
> 1. a "struct object" we can use to store flags
>
> 2. the type of the object, so we know whether we need to
> dereference it as a tag
>
> Instead, we can just use lookup_unknown_object to get an
> object struct, and then fill in just the type field using
> sha1_object_info (which, in the case of packed files, can
> find the information without actually inflating the object
> data).
>
> This can save time if you have a large number of refs, and
> the client isn't actually going to request those refs (e.g.,
> because most of them are already up-to-date).
>
> The downside is that we are no longer verifying objects that
> we advertise by fully parsing them (however, we do still
> know we actually have them, because sha1_object_info must
> find them to get the type). While we might fail to detect a
> corrupt object here, if the client actually fetches the
> object, we will parse (and verify) it then.
>...
This is an old news, but do you recall why this patch did not update
the code in mark_our_ref() that gets "struct object *o" from parse_object()
the same way and mark them with OUR_REF flag?
I was wondering about code consolidation like this.
upload-pack.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..609cd6c 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,18 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data);
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
" include-tag multi_ack_detailed";
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, "%s %s%c%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
@@ -740,10 +743,6 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, "%s %s^{}\n", sha1_to_hex(peeled), refname_nons);
return 0;
@@ -751,7 +750,7 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
- struct object *o = parse_object(sha1);
+ struct object *o = parse_object(sha1); /* lookup-unknown??? */
if (!o)
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
if (!(o->flags & OUR_REF)) {
^ permalink raw reply related
* Re: Question re. git remote repository
From: Philip Oakley @ 2013-01-18 23:10 UTC (permalink / raw)
To: David Lang; +Cc: Lang, David, 'Matt Seitz', git, Junio C Hamano
In-Reply-To: <alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz>
From: "David Lang" <david@lang.hm>
Sent: Friday, January 18, 2013 9:27 PM
> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang <david@lang.hm> writes:
>>
>>> What I would do is to have each developer have their own local copy
>>> that they are working on.
>>>
If you have a third machine to host the bare 'master' repo that would
provide additional security/backup to touy local machines.
[...]
>
> Junio, is there a really good place we should be pointing David where
> the different workflows are described and explained?
`git help workflows` perhaps.
Philip
^ permalink raw reply
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: John Keeping @ 2013-01-18 23:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <7vwqvap1q9.fsf@alter.siamese.dyndns.org>
On Fri, Jan 18, 2013 at 02:26:06PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>> On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
>>> These early versions may not be unstable in the "this does not
>>> behave as specified in the language specification for 3.x" sense,
>>> but for the purpose of running scripts meant to be executable by
>>> both 2.x and 3.x series, the early 3.x versions are not as good as
>>> later versions where Python folks started making deliberate effort
>>> to support them.
>>
>> As far as I'm aware (and having reviewed the release notes for 3.1, 3.2
>> and 3.3 as well as the planned features for 3.4), Unicode literals are
>> the only feature to have been added that was intended to make it easier
>> to support Python 2 and 3 in the same codebase.
>
> So there may be some other incompatibility lurking that we may run
> into later?
I doubt it - enough projects are running on Python 2 and 3 now that I
doubt there's anything unexpected left to hit.
>> Given that no code currently on pu uses Unicode literals, I don't see a
>> reason to specify a minimum version of Python 3 since we're already
>> restricting ourselves to features in 2.6.
>
> OK, at least that reasoning need to be kept somewhere, either in the
> documentation of in the log message.
I'll put it in the log message when I send this as a proper patch.
John
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 22:57 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Jonathan Nieder, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <7vpq12p17l.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Jean-Noël AVILA" <avila.jn@gmail.com> writes:
>
>> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>>> Junio C Hamano <gitster@pobox.com> writes:
>>> > How about doing something like this and set that variable in the
>>> > test instead? If STD_ONLY is not set, you will get everything, but
>>> > when STD_ONLY is set, we will stop reading from "help -a" when it
>>> > starts listing additional stuff.
>>
>> I tried both of your propositions but none made test 10 of t9902 pass.
>
> Do you have a leftover git-check-ignore or something from a previous
> build that is *not* known to "git" you just built?
"... in the build directory" was missing from the sentence. Sorry
about noise.
> Neither will help in such a case. The test pretty much runs with
> GIT_EXEC_PATH set to the build area, and we do want to be able to
> test what we have in the build area before we decide to install
> them, so that is nothing new.
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 22:37 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Jonathan Nieder, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <201301182323.55378.avila.jn@gmail.com>
"Jean-Noël AVILA" <avila.jn@gmail.com> writes:
> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano <gitster@pobox.com> writes:
>> > How about doing something like this and set that variable in the
>> > test instead? If STD_ONLY is not set, you will get everything, but
>> > when STD_ONLY is set, we will stop reading from "help -a" when it
>> > starts listing additional stuff.
>
> I tried both of your propositions but none made test 10 of t9902 pass.
Do you have a leftover git-check-ignore or something from a previous
build that is *not* known to "git" you just built?
Neither will help in such a case. The test pretty much runs with
GIT_EXEC_PATH set to the build area, and we do want to be able to
test what we have in the build area before we decide to install
them, so that is nothing new.
^ permalink raw reply
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: Junio C Hamano @ 2013-01-18 22:26 UTC (permalink / raw)
To: John Keeping
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <20130118220552.GF31172@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>> As more people have started trying to support Python 3 in the wild, it
>>> has become clear that it is often easier to have a single codebase that
>>> works with both Python 2 and Python 3, and not use 2to3.
>>>
>>> It is for this reason that the Unicode literal prefix was reintroduced.
>>
>> Yes, and from that perspective, placing floor on earlier 3.x makes
>> tons of sense, no?
>>
>> These early versions may not be unstable in the "this does not
>> behave as specified in the language specification for 3.x" sense,
>> but for the purpose of running scripts meant to be executable by
>> both 2.x and 3.x series, the early 3.x versions are not as good as
>> later versions where Python folks started making deliberate effort
>> to support them.
>
> As far as I'm aware (and having reviewed the release notes for 3.1, 3.2
> and 3.3 as well as the planned features for 3.4), Unicode literals are
> the only feature to have been added that was intended to make it easier
> to support Python 2 and 3 in the same codebase.
So there may be some other incompatibility lurking that we may run
into later?
> Given that no code currently on pu uses Unicode literals, I don't see a
> reason to specify a minimum version of Python 3 since we're already
> restricting ourselves to features in 2.6.
OK, at least that reasoning need to be kept somewhere, either in the
documentation of in the log message.
Thanks.
^ permalink raw reply
* Re: t9902 fails
From: Jean-Noël AVILA @ 2013-01-18 22:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <7vmww6qmck.fsf@alter.siamese.dyndns.org>
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> Junio C Hamano <gitster@pobox.com> writes:
> > How about doing something like this and set that variable in the
> > test instead? If STD_ONLY is not set, you will get everything, but
> > when STD_ONLY is set, we will stop reading from "help -a" when it
> > starts listing additional stuff.
I tried both of your propositions but none made test 10 of t9902 pass.
Am I supposed to run "make install" before running the test?
^ permalink raw reply
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: John Keeping @ 2013-01-18 22:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <7vip6uqlvl.fsf@alter.siamese.dyndns.org>
On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>> As more people have started trying to support Python 3 in the wild, it
>> has become clear that it is often easier to have a single codebase that
>> works with both Python 2 and Python 3, and not use 2to3.
>>
>> It is for this reason that the Unicode literal prefix was reintroduced.
>
> Yes, and from that perspective, placing floor on earlier 3.x makes
> tons of sense, no?
>
> These early versions may not be unstable in the "this does not
> behave as specified in the language specification for 3.x" sense,
> but for the purpose of running scripts meant to be executable by
> both 2.x and 3.x series, the early 3.x versions are not as good as
> later versions where Python folks started making deliberate effort
> to support them.
As far as I'm aware (and having reviewed the release notes for 3.1, 3.2
and 3.3 as well as the planned features for 3.4), Unicode literals are
the only feature to have been added that was intended to make it easier
to support Python 2 and 3 in the same codebase.
Given that no code currently on pu uses Unicode literals, I don't see a
reason to specify a minimum version of Python 3 since we're already
restricting ourselves to features in 2.6.
John
^ permalink raw reply
* RE: Question re. git remote repository
From: Matt Seitz @ 2013-01-18 21:56 UTC (permalink / raw)
To: Lang, David, David Lang; +Cc: git@vger.kernel.org
In-Reply-To: <201301181833.r0IIXNe7021768@smtpb01.one-mail.on.ca>
> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
>
> But ultimately, there shouldn't be a question of "if" you
> have a master repository but "where" you have the master repository, correct?
> Or in other words, it doesn't seem like you'd want to designate any one
> developer's local repository as also being the master repository, right?
You have two options:
1. Central model:
a. each developer has their own private repository
b. each developer uses "git commit" to commit changes into their own private repository
c. in addition, you also have a shared master repository
d. each developer uses "git push" to push their changes from their private repository to the shared master repository
e. each developer uses "git pull" to pull other developers' changes from the shared master repository
2. Peer-to-peer model:
a. each developer has their own private repository
b. each developer uses "git commit" to commit changes into their own private repository
c. each developer uses "git pull" to pull other developers' changes from other developers' private repositories
You can even mix these models. Say you have a 5 member team, and 2 members are working on a feature together. The 2 people working on the feature may use "git pull" to pull changes from each other's private repositories. Then, when the feature is ready, one of them can use "git push" to push the final version from their private repository into the team's shared repository.
What you don't want to do is this:
Single repository, multiple developers: just one repository, and every developer uses "git commit" to commit their changes into the same repository.
> My sense is that would defeat the purpose of the DVCS.
Not at all. The purpose of the DVCS is to allow each developer to have their own private repository where they can commit changes, while still allowing people to share changes from one repository to another. That's true whether you use the central model or the peer-to-peer model.
The traditional VCS has just one repository, and everyone has to commit their changes into that one central repository.
> We have access to many servers on our
> company's network, some of which we have full rights to, so there's no issue in
> regards to storage space.
That will work fine.
> I suppose another idea would be to have the master
> simply reside on one of the two developers local machines, so one of us would
> have both a local rep and the master rep and the other of us would have just a
> local rep.
That will also work. You could even omit the master rep. and just have each developer have a local repository. Each developer could then commit changes to their own local repository, and pull the other developer's changes from the other developer's local repository (the peer-to-peer model mentioned above).
> Or is it best to
> always have the master hosted on a machine with no other local reps?
There's no requirement to have the master hosted on a machine with no other local reps. The only issue is that the machine with the master rep. must be turned on for the other developers to push changes from their private repositories to the master repository. Having the master repository on a 24x7 server ensures it is always available to all developers. It also gives you another backup copy of your code, in case the developer's machine's storage fails or gets corrupted.
^ permalink raw reply
* Re: Question re. git remote repository
From: Junio C Hamano @ 2013-01-18 21:38 UTC (permalink / raw)
To: David Lang; +Cc: Lang, David, 'Matt Seitz', git@vger.kernel.org
In-Reply-To: <alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz>
David Lang <david@lang.hm> writes:
> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang <david@lang.hm> writes:
>> ...
>>> developers then do their work locally, and after a change has been
>>> reviewed, pull it into the master repository.
>>
>> s/pull it into/push it into/; I think.
>
> fair enough, I always think in terms of pulling from feature branches
> into the main repository so that any merge conflicts get resolved. I
> didn't describe this clearly enough.
If you are assuming that the "main repository" has a working tree
and somebody goes there, runs "git pull" and manually resolves
conflicts, that may be asking for trouble down the road. It may be
sufficient for two-person group as long as they coordinate among
themselves so that only one of them uses that working tree at the
"main repository" at a time.
But in general, it is more common to have a bare repository without
any working tree as the "main repository", let a push that conflicts
fail, and have the pusher fetch from the "main repository" and fix
up the conflicts in his working repository before he tries to push
the cleaned-up result. That gives the pusher a chance to re-test
the result of integration with what he did not see while he was
developing what he attempted to push.
"pull" and "pull -rebase" are two ways to do that "fetch from the
'main' and fix up" step.
^ permalink raw reply
* Re: Question re. git remote repository
From: David Lang @ 2013-01-18 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lang, David, 'Matt Seitz', git@vger.kernel.org
In-Reply-To: <7v622uqjch.fsf@alter.siamese.dyndns.org>
On Fri, 18 Jan 2013, Junio C Hamano wrote:
> David Lang <david@lang.hm> writes:
>
>> What I would do is to have each developer have their own local copy
>> that they are working on.
>>
>> I would then find a machine that is going to be on all the time (which
>> could be a developer's desktop), and create a master repository
>> there. Note that if this is on a developers desktop, this needs to be
>> a different repository ... from
>> what they use to do their work.
>>
>> developers then do their work locally, and after a change has been
>> reviewed, pull it into the master repository.
>
> s/pull it into/push it into/; I think.
fair enough, I always think in terms of pulling from feature branches into the
main repository so that any merge conflicts get resolved. I didn't describe this
clearly enough.
Junio, is there a really good place we should be pointing David where the
different workflows are described and explained?
for David
After the work is completed in the feature branches, you now have the problem of
how to combine this work in with whatever other work has taken place in the
meantime.
One common way to do this is to pull from the feature branch into the main tree.
If there are conflicts, git will help you identify them and resolve them (note
that some changes will not produce conflicts that git detects, but can still
result in non-working code)
developers can (and should) do a dry run on this if significant changes have
happened in the master. Create a new throw-away branch of the master tree and
merge your feature branch into that tree and see what happens. If everything
works, you are good to go. If you have massive conflicts, it may be worth doing
work to avoid the conflicts and then submit the result of that to the master
(also known as upstream)
With only two developers, you can have each of them do the merge work on a
temporary branch and then push the results upstream to the master, or you can
have one of them 'change hats' to be the release manager and work from the point
of view of the master to pull the changes in)
David Lang
^ permalink raw reply
* Re: Question re. git remote repository
From: Junio C Hamano @ 2013-01-18 21:20 UTC (permalink / raw)
To: David Lang; +Cc: Lang, David, 'Matt Seitz', git@vger.kernel.org
In-Reply-To: <alpine.DEB.2.02.1301181127590.21503@nftneq.ynat.uz>
David Lang <david@lang.hm> writes:
> What I would do is to have each developer have their own local copy
> that they are working on.
>
> I would then find a machine that is going to be on all the time (which
> could be a developer's desktop), and create a master repository
> there. Note that if this is on a developers desktop, this needs to be
> a different repository ... from
> what they use to do their work.
>
> developers then do their work locally, and after a change has been
> reviewed, pull it into the master repository.
s/pull it into/push it into/; I think.
^ permalink raw reply
* Re: [PATCH 1/6] config: add helper function for parsing key names
From: Junio C Hamano @ 2013-01-18 20:53 UTC (permalink / raw)
To: Jeff King; +Cc: Joachim Schmitz, René Scharfe, git
In-Reply-To: <7vehhm4bof.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> ... did you have any comment on
>> the "struct config_key" alternative I sent as a follow-up?
>
> I did read it but I cannot say I did so very carefully. My gut
> reaction was that the "take the variable name and section name,
> return the subsection name pointer and length, if there is any, and
> the key" made it readable enough. The proposed interface to make
> and lend a copy to the caller does make it more readble, but I do
> not know if that is worth doing. Neutral-to-slightly-in-favor, I
> would say.
Now I re-read that "struct config_key" thing, I would have to say
that the idea of giving split and NUL-terminated strings to the
callers is good, but the "cheat" looks somewhat brittle for all the
reasons that come from using a static buffer (which you already
mentioned). As I do not offhand think of a better alternative, I'd
say we leave it for another day.
^ permalink raw reply
* Re: [PATCH v3] am: invoke perl's strftime in C locale
From: Junio C Hamano @ 2013-01-18 20:36 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Jeff King, Antoine Pelisse, git
In-Reply-To: <20130115190517.GB7963@altlinux.org>
"Dmitry V. Levin" <ldv@altlinux.org> writes:
> This fixes "hg" patch format support for locales other than C and en_*.
> Before the change, git-am was making "Date:" line from hg changeset
> metadata according to the current locale, and this line was rejected
> later with "invalid date format" diagnostics because localized date
> strings are not supported.
>
> Reported-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
> ---
>
> v3: alternative implementation using setlocale(LC_TIME, "C")
>
> git-am.sh | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/git-am.sh b/git-am.sh
> index c682d34..8677d8c 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -334,7 +334,8 @@ split_patches () {
> # Since we cannot guarantee that the commit message is in
> # git-friendly format, we put no Subject: line and just consume
> # all of the message as the body
> - perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
> + perl -M'POSIX qw(strftime :locale_h)' -ne '
> + BEGIN { setlocale(LC_TIME, "C"); $subject = 0 }
I still haven't convinced myself that this is an improvement over
the simple "LC_ALL=C LANG=C perl ..." approach.
This alternative might be theoretically more correct if we cared
about the error and other messages from this Perl invocation, but it
requires that everybody's Perl implementation correctly supports the
additional -M'POSIX ":locale_h"' and "setlocale(LC_TIME, ...)".
I am tempted to use the previous one that puts the whole process
under LC_ALL=C instead, unless I hear a "we already depend on that
elsewhere, look at $that_code".
Thanks.
> if ($subject) { print ; }
> elsif (/^\# User /) { s/\# User/From:/ ; print ; }
> elsif (/^\# Date /) {
^ permalink raw reply
* RE: Question re. git remote repository
From: David Lang @ 2013-01-18 20:27 UTC (permalink / raw)
To: Lang, David; +Cc: 'Matt Seitz', git@vger.kernel.org
In-Reply-To: <201301181833.r0IIXNGb027544@smtpb02.one-mail.on.ca>
What I would do is to have each developer have their own local copy that they
are working on.
I would then find a machine that is going to be on all the time (which could be
a developer's desktop), and create a master repository there. Note that if this
is on a developers desktop, this needs to be a different repository (or at the
very least a different branch) from what they use to do their work.
developers then do their work locally, and after a change has been reviewed,
pull it into the master repository.
This can even be done if you only have one developer (although then you may just
use branches instead of a separate repository)
The idea is that when you start working on a new feature, you create a new
branch from the master, implement your new feature, and then (after testing)
merge the completed feature into the master branch/repository.
If developers are working on multiple things at once, they should have multiple
branches. This is a hard habit to get into.
The tendancy is that while you are in changing code, you see something unrelated
that needs fixing, so you fix it and go back to what you were doing.
You should try to get into the habit of not fixing unrelated things in one
branch (or having a separate branch you use only for trivial fixes)
The idea is that each feature branch should have one set of related changes in
it, so that you can merge in a branch when it's ready and not end up with one
fix being tied in to another one,
David Lang
On Fri, 18 Jan 2013, Lang, David wrote:
> Hi Matt and David,
>
> Your responses have been very helpful for this newbie...thanks very much! I have a good sense now of the difference btw a CVCS and a DVCS. Here are two more questions...
>
> 1. I now get the sense that there's quite a few options in regards to the way that any one group implements their "origin"/"master"/<fill in your favourite name> repository. But ultimately, there shouldn't be a question of "if" you have a master repository but "where" you have the master repository, correct? Or in other words, it doesn't seem like you'd want to designate any one developer's local repository as also being the master repository, right? My sense is that would defeat the purpose of the DVCS.
>
> 2. Assuming I'm right about question #1, our first hurdle is where to host the master repository. Could you provide any suggestions for a setup based on our VERY simple department model? I work for a small IT department with a grand total of TWO developers (who sit five feet apart from one another)! The reason we're looking at a VCS is because I was hired a few months ago and the dept never needed one before now. We realize that git will be overkill for what we need but frankly anything will be overkill for what we need, and since git seems to be so well regarded in the community (and free) it looks like a good choice.
>
> So the question is, how would either of you recommend we set up our master repository? We definitely want to keep everything "in house" so off-site hosting isn't something we'd consider. We have access to many servers on our company's network, some of which we have full rights to, so there's no issue in regards to storage space. I suppose another idea would be to have the master simply reside on one of the two developers local machines, so one of us would have both a local rep and the master rep and the other of us would have just a local rep. This would simplify the model. What do you think? Or is it best to always have the master hosted on a machine with no other local reps?
>
> David
^ permalink raw reply
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: Junio C Hamano @ 2013-01-18 20:25 UTC (permalink / raw)
To: John Keeping
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <20130118193501.GE31172@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
>>> + - Where required libraries do not restrict us to Python 2, we try to
>>> + also be compatible with Python 3. In this case we use
>>> + `from __future__ import unicode_literals` if we need to differentiate
>>> + Unicode string literals, rather than prefixing Unicode strings with
>>> + 'u' since the latter is not supported in Python versions 3.0 - 3.2.
>>
>> "In this case"? In what case? This document will stay effective
>> long after you settle one particular backward incompatibility Python
>> 3 introduced, namely, the unicode literal issues. It is just one
>> "example".
>
> I meant "in the case where you are supporting Python 3" but I suspect it
> would be better to move the unicode_literals sentence to a new bullet.
> Or maybe we should just remove it - I haven't seen a case in the current
> Git source where we need Unicode literals.
Yeah, "we support 2.x" and "we suport 3.x" may want to be combined,
but listing individual specifics as separate points to watch out for
would make it much more readable.
> As more people have started trying to support Python 3 in the wild, it
> has become clear that it is often easier to have a single codebase that
> works with both Python 2 and Python 3, and not use 2to3.
>
> It is for this reason that the Unicode literal prefix was reintroduced.
Yes, and from that perspective, placing floor on earlier 3.x makes
tons of sense, no?
These early versions may not be unstable in the "this does not
behave as specified in the language specification for 3.x" sense,
but for the purpose of running scripts meant to be executable by
both 2.x and 3.x series, the early 3.x versions are not as good as
later versions where Python folks started making deliberate effort
to support them.
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 20:15 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jean-Noël AVILA, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <7v8v7qsagd.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> How about doing something like this and set that variable in the
> test instead? If STD_ONLY is not set, you will get everything, but
> when STD_ONLY is set, we will stop reading from "help -a" when it
> starts listing additional stuff.
>
> contrib/completion/git-completion.bash | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index a4c48e1..415a078 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -534,7 +534,8 @@ __git_complete_strategy ()
> __git_list_all_commands ()
> {
> local i IFS=" "$'\n'
> - for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
> + for i in $(LANG=C LC_ALL=C git help -a |
> + sed -n ${GIT_HELP_STD_ONLY+-e /^git.*elsewhere/q} -e '/^ [a-zA-Z0-9]/p')
> do
> case $i in
> *--*) : helper pattern;;
Alternatively, we could do this and replace everything inside $()
with "git help --standard", but that requires the completion script
update to go in sync with the core update, which is a downside.
builtin/help.c | 21 +++++++++++++++++----
help.c | 3 +++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index bd86253..e6b9b5f 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -36,11 +36,16 @@ enum help_format {
static const char *html_path;
-static int show_all = 0;
+#define HELP_ALL 1
+#define HELP_STANDARD 2
+static int show_what;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
+ HELP_ALL),
+ OPT_SET_INT(0, "standard", &show_what, N_("list subcommands that comes with git"),
+ HELP_STANDARD),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -436,19 +441,27 @@ int cmd_help(int argc, const char **argv, const char *prefix)
int nongit;
const char *alias;
enum help_format parsed_help_format;
- load_command_list("git-", &main_cmds, &other_cmds);
argc = parse_options(argc, argv, prefix, builtin_help_options,
builtin_help_usage, 0);
parsed_help_format = help_format;
- if (show_all) {
+ load_command_list("git-", &main_cmds,
+ show_what == HELP_STANDARD ? NULL : &other_cmds);
+
+ if (show_what == HELP_ALL) {
git_config(git_help_config, NULL);
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
return 0;
}
+ if (show_what == HELP_STANDARD) {
+ int i;
+ for (i = 0; i < main_cmds.cnt; i++)
+ printf("%s\n", main_cmds.names[i]->name);
+ return 0;
+ }
if (!argv[0]) {
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
diff --git a/help.c b/help.c
index 2a42ec6..3e6b04c 100644
--- a/help.c
+++ b/help.c
@@ -182,6 +182,9 @@ void load_command_list(const char *prefix,
uniq(main_cmds);
}
+ if (!other_cmds)
+ return;
+
if (env_path) {
char *paths, *path, *colon;
path = paths = xstrdup(env_path);
^ permalink raw reply related
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: John Keeping @ 2013-01-18 19:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <7vvcauqpn4.fsf@alter.siamese.dyndns.org>
On Fri, Jan 18, 2013 at 11:04:15AM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
>> index 69f7e9b..baf3b41 100644
>> --- a/Documentation/CodingGuidelines
>> +++ b/Documentation/CodingGuidelines
>> @@ -179,6 +179,22 @@ For C programs:
>> - Use Git's gettext wrappers to make the user interface
>> translatable. See "Marking strings for translation" in po/README.
>>
>> +For Python scripts:
>> +
>> + - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
>> +
>> + - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
>> +
>> + - Where required libraries do not restrict us to Python 2, we try to
>> + also be compatible with Python 3. In this case we use
>> + `from __future__ import unicode_literals` if we need to differentiate
>> + Unicode string literals, rather than prefixing Unicode strings with
>> + 'u' since the latter is not supported in Python versions 3.0 - 3.2.
>
> "In this case"? In what case? This document will stay effective
> long after you settle one particular backward incompatibility Python
> 3 introduced, namely, the unicode literal issues. It is just one
> "example".
I meant "in the case where you are supporting Python 3" but I suspect it
would be better to move the unicode_literals sentence to a new bullet.
Or maybe we should just remove it - I haven't seen a case in the current
Git source where we need Unicode literals.
> That example somehow tells me that early versions of Python 3.x
> series may be too buggy and not worth worrying about, and we may
> want to set a floor for Python 3.x series, too, with something
> like:
[snip]
> I am not actively advocating to disqualify early 3.x; I am just
> suggesting that doing so may be a viable escape hatch for us that
> does not harm real users. If you and others who know Python better
> think there isn't any problem that makes it too cumbersome to
> support both late 2.x and 3.0/3.1, there is no reason to set the
> floor at 3.2.
>
> I just have this feeling that we might be better off treating them
> as 0.x releases of a new software called Python3, that happens to be
> similar to the Python we know.
I originally thought about putting a floor of 3.3 (which is where
Unicode literals were reintroduced) but that was only released in
September and as far as I'm aware Unicode literals are the only reason
to have a restriction on Python 3 versions, given that we support Python
2.6 - standard library features should be equivalent.
I don't think Python 3.0 is any less stable than any other 3.x release,
it's just that it was the first release which attempted a clean break
from backwards compatibility. From the point of view of features
supported, Python 2.6 and 3.0 should be roughly equivalent - they were
released together with the intent that 2.6 should make it possible to
write code that ports to 3.0 easily, using 2to3.
As more people have started trying to support Python 3 in the wild, it
has become clear that it is often easier to have a single codebase that
works with both Python 2 and Python 3, and not use 2to3.
It is for this reason that the Unicode literal prefix was reintroduced.
From the specification reintroducing it [1]:
Complaint: Python 3 shouldn't be made worse just to support porting
from Python 2
This is indeed one of the key design principles of Python 3. However,
one of the key design principles of Python as a whole is that
"practicality beats purity".
[1] http://www.python.org/dev/peps/pep-0414/#complaint-python-3-shouldn-t-be-made-worse-just-to-support-porting-from-python-2
John
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox