* 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
* [PATCH v2] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Brandon Casey @ 2013-01-18 19:24 UTC (permalink / raw)
To: gitster; +Cc: git, schwab, felipe.contreras, Brandon Casey
In-Reply-To: <CA+sFfMd7hurR=4n1r9RLtMYoxnM_LFH5j1McJc8+8_JumqviLg@mail.gmail.com>
When commit d8b45314 began separating the zsh completion from the bash
completion, it introduced a zsh completion "bridge" section into the bash
completion script for zsh users to use until they migrated to the zsh
script. The zsh '+=()' append-to-array notation prevents bash 3.00.15 on
CentOS 4.x from loading the completion script and breaks test 9902. We can
easily work around this by using standard Bash array notation.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> + array[$(($#array+1))]="$c"
>
> You don't need $(( )) since the array index is already evaluated as an
> arithmethic expression.
Fixed.
-Brandon
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..2f99420 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2431,7 +2431,7 @@ if [[ -n ${ZSH_VERSION-} ]]; then
--*=*|*.) ;;
*) c="$c " ;;
esac
- array+=("$c")
+ array[$#array+1]="$c"
done
compset -P '*[=:]'
compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
--
1.7.8.4
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Brandon Casey @ 2013-01-18 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, felipe.contreras, git
In-Reply-To: <7vr4liqpg4.fsf@alter.siamese.dyndns.org>
On Fri, Jan 18, 2013 at 11:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>> Brandon Casey <drafnel@gmail.com> writes:
>>>
>>>> + array[$(($#array+1))]="$c"
>>>
>>> You don't need $(( )) since the array index is already evaluated as an
>>> arithmethic expression.
>>
>> Ah, I didn't know that. Thanks.
>>
>> I think Junio will probably fix this up if he thinks it's worth it,
>> but I can resubmit if necessary.
>
> Please; I do not have mental bandwidth to keep track of contrib/
> material myself.
No problem.
-Brandon
^ permalink raw reply
* Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Junio C Hamano @ 2013-01-18 19:08 UTC (permalink / raw)
To: Brandon Casey; +Cc: Andreas Schwab, felipe.contreras, git
In-Reply-To: <CA+sFfMd6FLchoOcUpNZ3AxTLNp3qe=VjijRid4sWf-A3_w88qw@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Brandon Casey <drafnel@gmail.com> writes:
>>
>>> + array[$(($#array+1))]="$c"
>>
>> You don't need $(( )) since the array index is already evaluated as an
>> arithmethic expression.
>
> Ah, I didn't know that. Thanks.
>
> I think Junio will probably fix this up if he thinks it's worth it,
> but I can resubmit if necessary.
Please; I do not have mental bandwidth to keep track of contrib/
material myself.
^ permalink raw reply
* Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Brandon Casey @ 2013-01-18 19:07 UTC (permalink / raw)
To: Andreas Schwab; +Cc: gitster, felipe.contreras, git
In-Reply-To: <m2obgmjzz0.fsf@igel.home>
On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> + array[$(($#array+1))]="$c"
>
> You don't need $(( )) since the array index is already evaluated as an
> arithmethic expression.
Ah, I didn't know that. Thanks.
I think Junio will probably fix this up if he thinks it's worth it,
but I can resubmit if necessary.
-Brandon
^ permalink raw reply
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: Junio C Hamano @ 2013-01-18 19:04 UTC (permalink / raw)
To: John Keeping
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <20130118180639.GD31172@serenity.lan>
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".
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:
- The code should be compatible with 2.6 and newer versions of
Python 2.x series; 2.5 and older are not supported anymore.
- The code should also be comptabile with 3.2 and newer versions
of Python 3.x series; 3.1 and older are not mature enough and
have too many problems to write scripts that work on it and
solid 2.x at the same time.
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.
^ permalink raw reply
* Re: merge vs. rebase question
From: Dennis Putnam @ 2013-01-18 18:59 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CABURp0rTNh4Xe4h6RwvDgQaBKJFq-ami-wO+X0mR5hiubaF7mw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]
Thanks for the reply. I'm afraid this question has become moot. I can no
longer reproduce the problem as it is now working as expected. I did
find an incorrect ownership on one of the 'objects' sub-directories but
I would think that should have given me an error. Perhaps I used root at
the wrong time to do something and that changed the ownership. In any
case there is not much I can do at this point since the problem no
longer exists.
On 1/18/2013 1:38 PM, Phil Hord wrote:
> On Thu, Jan 17, 2013 at 9:14 AM, Dennis Putnam <dap1@bellsouth.net> wrote:
>> As a git noob I am having trouble understanding when to use which
>> commands. I have a repository (bare) on my Linux server. I also created
>> a build directory as a local repository. In my build script I do a 'git
>> pull' to make sure the build directory is up to date. No changes are
>> made to my source so this repository never does an 'add' or 'commit'.
>> When I run my script with 'pull', the output indicates that changes were
>> found and seems to have pulled them into the local directory. However,
>> when I look at the resulting source, none of the expected changes show
>> up. I then tried a 'fetch' and 'rebase'. That worked but I don't
>> understand why. I thought 'pull' did a 'fetch' and a 'merge' so I don't
>> understand why a 'fetch' and 'rebase' worked but 'fetch' and 'merge' did
>> not. Unless my understanding of what 'pull' does is wrong. In my case,
>> what should I be using in my script to assure that the build directory
>> is current?
> If your build directory never has any source changes or new commits,
> then pull is the right thing to do. You might want to use 'git pull
> --ff-only' to guarantee that your build directory is not creating
> merges unexpectedly.
>
> You did not provide enough information to help figure out why your
> pull is failing to achieve the results you expect. I suggest you
> perform the pull manually in your build directory. If it fails, git
> should tell you why. If it reports success but actually fails, you
> can post a detailed explanation of the problem here so someone can
> suggest the cause.
>
> Phil
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply
* Re: Unable to convert a subversion repo to git
From: Michael J Gruber @ 2013-01-18 18:59 UTC (permalink / raw)
To: Timothy Kretschmer, Git Mailing List
In-Reply-To: <CAO2=c4k8aexmjNUCSigGDVn_5rzVLp1a2C6ngoke-6eU=8WiWQ@mail.gmail.com>
Timothy Kretschmer venit, vidit, dixit 18.01.2013 17:59:
> The exact names of the branches are "CMT_PHASE3" and
> "BlueSimViewer5.0_20110316_Branch"
Just to be sure, not to doubt you: the svn branch name is
"BlueSimViewer5.0_20110316_Branch" and thus differs from the name
reported by git-svn? Are there maybe unprintable characters/control
codes or something in the svn branch name?
Somehow, git-svn is using an improper refname.
> File system on the converting machine is ext4. SVN server is hosted on
> a Fedora 8 box , running subversion 1.4.x.
> To move forward, I commented out the problematic branches under
> .git/packed-refs. Conversion continued but skipped the troubled
> branches.
> Still on the road of finding a way to include those branches in the conversion.
>
> On Fri, Jan 18, 2013 at 11:48 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Timothy Kretschmer venit, vidit, dixit 16.01.2013 15:06:
>>> I am seeing the following output while converting a subversion repo to git.
>>>
>>> >Found possible branch point: <repo-url>/trunk =>
>>> <repo-url>/branches/CMT_PHASE3, 18441
>>>> fatal: Not a valid object name refs/remotes/BlueSimViewer 5.0 20110316 Branch
>>>> cat-file commit refs/remotes/BlueSimViewer 5.0 20110316 Branch: command returned error: 128
>>>
>>> The command I am running to convert the repo is
>>>
>>>> git svn clone <repo-url> -A authors-transform.txt --stdlayout bluebox-git > svnlist
>>>
>>> I am running git version 1.8.1.1 on an Ubuntu 12.10 server. I am happy
>>> to provide any other information that would be helpful.
>>>
>>> I appreciate any assistance you can provide in this matter,
>>> -Tim
>>
>> git-svn should cope with funky branch names. What is the exact name of
>> the "CMT..." and "BlueSimViewer..." branches? Are you using a case
>> challenged file system or just some standard linux fs?
>>
>> Michael
>>
^ permalink raw reply
* RE: Question re. git remote repository
From: Lang, David @ 2013-01-18 18:33 UTC (permalink / raw)
To: 'Matt Seitz', David Lang; +Cc: git@vger.kernel.org
In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com>
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
-----Original Message-----
From: Matt Seitz [mailto:mseitz@mhseitz.onmicrosoft.com]
Sent: Friday, January 18, 2013 12:52 AM
To: Lang, David; David Lang
Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Stephen Smith
Subject: RE: Question re. git remote repository
From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]
> I thought the idea was that each developer installed git locally on
> their machines
Yes.
> and (as needed) committed their changes to the master repository which
> resides externally to any of the local machines, such as on a network
> server
Yes, but committing their changes to the master repository is a two step process:
1. Each developer first commits their changes to their personal repository using the "git commit" command.
2. Each developer pushes their changes from their personal repository to the master repository with the "git push" command
> (and which I'm assuming has git installed locally as well).
Maybe.
If the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol.
If the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB. The git documentation refers to this method as the "file protocol".
The other David Lang (david@lang.hm) believes that using "git push" using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using "git push" over NFS or CIFS/SMB is safe and reliable:
http://permalink.gmane.org/gmane.comp.version-control.git/122670
The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable:
https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F
This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient.
Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited.
If you have received this e-mail in error, please contact the sender and delete all copies.
Opinions, conclusions or other information contained in this e-mail may not be that of the organization.
^ permalink raw reply
* Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
From: Linus Torvalds @ 2013-01-18 18:52 UTC (permalink / raw)
To: Phil Hord
Cc: John Keeping, Antoine Pelisse, Max Horn, git, Johannes Sixt,
Junio C Hamano
In-Reply-To: <CABURp0pj35j7+W_0gYNud2uuEoahugOMBW9ezTgPZ7YvgnBz8w@mail.gmail.com>
On Fri, Jan 18, 2013 at 9:15 AM, Phil Hord <phil.hord@gmail.com> wrote:
>
> Yes, I can tell by the wording of the error message that you are right
> and clang has a problem. But the git code it complained about does
> have a real problem, because the result of "signed int a = ULONG_MAX"
> is implementation-defined.
Only theoretically.
Git won't work on machines that don't have 8-bit bytes anyway, so
worrying about the theoretical crazy architectures that aren't two's
complement etc isn't something I'd care about.
There's a whole class of "technically implementation-defined" issues
in C that simply aren't worth caring for. Yes, the standard is written
so that it works on machines that aren't byte-addressable, or EBCDIC
or have things like 18-bit words and 36-bit longwords. Or 16-bit "int"
for microcontrollers etc.
That doesn't make those "implementation-defined" issues worth worrying
about these days. A compiler writer could in theory make up some
idiotic rules that are still "valid by the C standard" even on modern
machines, but such a compiler should simply not be used, and the
compiler writer in question should be called out for being an ass-hat.
Paper standards are only worth so much. And that "so much" really
isn't very much.
Linus
^ permalink raw reply
* Re: merge vs. rebase question
From: Phil Hord @ 2013-01-18 18:38 UTC (permalink / raw)
To: Dennis Putnam; +Cc: git@vger.kernel.org
In-Reply-To: <50F8073F.90304@bellsouth.net>
On Thu, Jan 17, 2013 at 9:14 AM, Dennis Putnam <dap1@bellsouth.net> wrote:
> As a git noob I am having trouble understanding when to use which
> commands. I have a repository (bare) on my Linux server. I also created
> a build directory as a local repository. In my build script I do a 'git
> pull' to make sure the build directory is up to date. No changes are
> made to my source so this repository never does an 'add' or 'commit'.
> When I run my script with 'pull', the output indicates that changes were
> found and seems to have pulled them into the local directory. However,
> when I look at the resulting source, none of the expected changes show
> up. I then tried a 'fetch' and 'rebase'. That worked but I don't
> understand why. I thought 'pull' did a 'fetch' and a 'merge' so I don't
> understand why a 'fetch' and 'rebase' worked but 'fetch' and 'merge' did
> not. Unless my understanding of what 'pull' does is wrong. In my case,
> what should I be using in my script to assure that the build directory
> is current?
If your build directory never has any source changes or new commits,
then pull is the right thing to do. You might want to use 'git pull
--ff-only' to guarantee that your build directory is not creating
merges unexpectedly.
You did not provide enough information to help figure out why your
pull is failing to achieve the results you expect. I suggest you
perform the pull manually in your build directory. If it fails, git
should tell you why. If it reports success but actually fails, you
can post a detailed explanation of the problem here so someone can
suggest the cause.
Phil
^ permalink raw reply
* [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: John Keeping @ 2013-01-18 18:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [2], there isn't any disagreement about using
2.6 as a base (see also [3]).
- The Git INSTALL document currently says:
Python version 2.6 or later is needed to use the git-p4
interface to Perforce.
- Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
significantly easier [4].
- Following Pete's comment [5] I tested Python 2.6.0 and it does
support bytes literals, as suggested by [4] but contradicted by [6].
- Advocating Python 3 support in all scripts is currently unrealistic
because:
- 'p4 -G' provides output in a format that is very hard to use with
Python 3 (and its documentation claims Python 3 is unsupported).
- Mercurial does not support Python 3.
- Bazaar does not support Python 3.
- But we should try to make new scripts compatible with Python 3
because all new Python development is happening on version 3 and the
Python community will eventually stop supporting Python 2 [7].
I chose to recommend `from __future__ import unicode_literals` since it
provides the widest range of compatibility (2.6+ and 3.0+) while
allowing us to be explicit about bytes vs. Unicode. The alternative
would be to advocate using the 'u' prefix on Unicode strings but this
isn't available in versions 3.0 - 3.2 (it is reintroduced in version 3.3
as a no-op in order to make it easier to write scripts targeting a wide
range of Python versions without needing to use 2to3 [1]). In reality I
doubt we will ever need to worry about this since ASCII strings will
just work in both Python 2 and Python 3.
[1] http://www.python.org/dev/peps/pep-0414/
[2] http://thread.gmane.org/gmane.comp.version-control.git/210329
[3] http://article.gmane.org/gmane.comp.version-control.git/210429
[4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
[5] http://article.gmane.org/gmane.comp.version-control.git/213830
[6] http://docs.python.org/2.6/reference/lexical_analysis.html#literals
[7] http://www.python.org/dev/peps/pep-0404/
---
Documentation/CodingGuidelines | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
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.
+
+ - We use the 'b' prefix for bytes literals. Note that even though
+ the Python documentation for version 2.6 does not mention this
+ prefix it is supported since version 2.6.0.
+
Writing Documentation:
Every user-visible change should be reflected in the documentation.
--
1.8.1
^ permalink raw reply related
* Re: GIT get corrupted on lustre
From: Eric Chamberland @ 2013-01-18 17:50 UTC (permalink / raw)
To: Pyeron, Jason J CTR (US)
Cc: Maxime Boissonneault, Philippe Vaucher, git@vger.kernel.org,
Sébastien Boisvert
In-Reply-To: <871B6C10EBEFE342A772D1159D1320853A044B42@umechphj.easf.csd.disa.mil>
Good idea!
I did a strace and here is the output with the error:
http://www.giref.ulaval.ca/~ericc/strace_git_error.txt
Hope it will be insightful!
Eric
On 01/17/2013 12:17 PM, Pyeron, Jason J CTR (US) wrote:
> Sorry, I am in cygwin mode, and I had crossed wires in my head. s/ProcessMon/strace/
>
>> -----Original Message-----
>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
>> Behalf Of Maxime Boissonneault
>> Sent: Thursday, January 17, 2013 11:41 AM
>> To: Pyeron, Jason J CTR (US)
>> Cc: Eric Chamberland; Philippe Vaucher; git@vger.kernel.org; Sébastien
>> Boisvert
>> Subject: Re: GIT get corrupted on lustre
>>
>> I don't know of any lustre filesystem that is used on Windows. Barely
>> anybody uses Windows in the HPC industry.
>> This is a Linux cluster.
>>
>> Maxime Boissonneault
>>
>> Le 2013-01-17 11:40, Pyeron, Jason J CTR (US) a écrit :
>>>> -----Original Message-----
>>>> From: Eric Chamberland
>>>> Sent: Thursday, January 17, 2013 11:31 AM
>>>>
>>>> On 01/17/2013 09:23 AM, Philippe Vaucher wrote:
>>>>>> Anyone has a new idea?
>>>>> Did you try Jeff King's code to confirm his idea?
>>>>>
>>>>> Philippe
>>>>>
>>>> Yes I did, but it was running without any problem....
>>>>
>>>> I find that my test case is "simple" (fresh git clone then "git gc"
>> in
>>>> a
>>>> crontab), I bet anyone who has access to a Lustre filesystem can
>>>> reproduce the problem... The problem is to have such a filesystem
>> to
>>>> do
>>>> the tests....
>>> Stabbing in the dark, but can you log the details with ProcessMon?
>>>
>>> http://technet.microsoft.com/en-us/sysinternals/bb896645
>>>
>>>> But I am available to do it...
>>> -Jason
>>
>>
>> --
>> ---------------------------------
>> Maxime Boissonneault
>> Analyste de calcul - Calcul Québec, Université Laval
>> Ph. D. en physique
>>
>> --
>> 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: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
From: Phil Hord @ 2013-01-18 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: John Keeping, Antoine Pelisse, Max Horn, git, Johannes Sixt,
Junio C Hamano
In-Reply-To: <CA+55aFxYSX2iYPSafKdCDSfWSMfQxP3R3Hqh8GuiiR6EbWfk3w@mail.gmail.com>
On Thu, Jan 17, 2013 at 11:44 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jan 17, 2013 at 3:00 AM, John Keeping <john@keeping.me.uk> wrote:
>>
>> There's also a warning that triggers with clang 3.2 but not clang trunk, which
>> I think is a legitimate warning - perhaps someone who understands integer type
>> promotion better than me can explain why the code is OK (patch->score is
>> declared as 'int'):
>>
>> builtin/apply.c:1044:47: warning: comparison of constant 18446744073709551615
>> with expression of type 'int' is always false
>> [-Wtautological-constant-out-of-range-compare]
>> if ((patch->score = strtoul(line, NULL, 10)) == ULONG_MAX)
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~
>
> The warning seems to be very very wrong, and implies that clang has
> some nasty bug in it.
>
> Since patch->score is 'int', and UNLONG_MAX is 'unsigned long', the
> conversion rules for the comparison is that the int result from the
> assignment is cast to unsigned long. And if you cast (int)-1 to
> unsigned long, you *do* get ULONG_MAX. That's true regardless of
> whether "long" has the same number of bits as "int" or is bigger. The
> implicit cast will be done as a sign-extension (unsigned long is not
> signed, but the source type of 'int' *is* signed, and that is what
> determines the sign extension on casting).
>
> So the "is always false" is pure and utter crap. clang is wrong, and
> it is wrong in a way that implies that it actually generates incorrect
> code. It may well be worth making a clang bug report about this.
>
> That said, clang is certainly understandably confused. The code
> depends on subtle conversion rules and bit patterns, and is clearly
> very confusingly written.
>
> So it would probably be good to rewrite it as
>
> unsigned long val = strtoul(line, NULL, 10);
> if (val == ULONG_MAX) ..
> patch->score = val;
>
> instead. At which point you might as well make the comparison be ">=
> INT_MAX" instead, since anything bigger than that is going to be
> bogus.
>
> So the git code is probably worth cleaning up, but for git it would be
> a cleanup. For clang, this implies a major bug and bad code
> generation.
Yes, I can tell by the wording of the error message that you are right
and clang has a problem. But the git code it complained about does
have a real problem, because the result of "signed int a = ULONG_MAX"
is implementation-defined. It cannot be guaranteed or expected that
patch->score will ever be assigned -1 there, and so the comparison may
always be false. I guess the warning is correct, but only
accidentally. :-)
Your rewrite is more sane and corrects the problem, I think.
Phil
^ 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