* 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
* Re: What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Junio C Hamano @ 2013-01-18 16:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50F96589.4010408@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 01/18/2013 01:14 AM, Junio C Hamano wrote:
>> [...]
>> * mh/imap-send-shrinkage (2013-01-15) 14 commits
>> - imap-send.c: simplify logic in lf_to_crlf()
>> - imap-send.c: fold struct store into struct imap_store
>> - imap-send.c: remove unused field imap_store::uidvalidity
>> - imap-send.c: use struct imap_store instead of struct store
>> - imap-send.c: remove unused field imap_store::trashnc
>> - imap-send.c: remove namespace fields from struct imap
>> - imap-send.c: remove struct imap argument to parse_imap_list_l()
>> - imap-send.c: inline parse_imap_list() in parse_list()
>> - imap-send.c: remove some unused fields from struct store
>> - imap-send.c: remove struct message
>> - imap-send.c: remove struct store_conf
>> - iamp-send.c: remove unused struct imap_store_conf
>> - imap-send.c: remove struct msg_data
>> - imap-send.c: remove msg_data::flags, which was always zero
>>
>> Remove a lot of unused code from "git imap-send".
>>
>> With a further comment fixup in patch #6, this seems ready for
>> 'next'.
>> Expecting a reroll.
>
> I'm confused. It seems like you are referring to the comment
> improvement suggested by Jonathan Nieder...
It was an indication that I just forgot our previous exchange in
which I said "the remaining issues are so minor I can squash these
in". Sorry about that.
Will merge to 'next'.
Thanks.
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 16:49 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: <20130118000454.GI13449@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH. I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts?
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;;
^ permalink raw reply related
* Re: Unable to convert a subversion repo to git
From: Michael J Gruber @ 2013-01-18 16:48 UTC (permalink / raw)
To: Timothy Kretschmer; +Cc: git
In-Reply-To: <CAO2=c4nr8PsbHmyKptWewQMmpqWP=YasKZSnCuB9CCkExpSF8A@mail.gmail.com>
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: What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Michael Haggerty @ 2013-01-18 15:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsj5zs5y2.fsf@alter.siamese.dyndns.org>
On 01/18/2013 01:14 AM, Junio C Hamano wrote:
> [...]
> * mh/imap-send-shrinkage (2013-01-15) 14 commits
> - imap-send.c: simplify logic in lf_to_crlf()
> - imap-send.c: fold struct store into struct imap_store
> - imap-send.c: remove unused field imap_store::uidvalidity
> - imap-send.c: use struct imap_store instead of struct store
> - imap-send.c: remove unused field imap_store::trashnc
> - imap-send.c: remove namespace fields from struct imap
> - imap-send.c: remove struct imap argument to parse_imap_list_l()
> - imap-send.c: inline parse_imap_list() in parse_list()
> - imap-send.c: remove some unused fields from struct store
> - imap-send.c: remove struct message
> - imap-send.c: remove struct store_conf
> - iamp-send.c: remove unused struct imap_store_conf
> - imap-send.c: remove struct msg_data
> - imap-send.c: remove msg_data::flags, which was always zero
>
> Remove a lot of unused code from "git imap-send".
>
> With a further comment fixup in patch #6, this seems ready for
> 'next'.
> Expecting a reroll.
I'm confused. It seems like you are referring to the comment
improvement suggested by Jonathan Nieder [1] that you have already
incorporated [2] into mh/imap-send-shrinkage. If you think there is
something that needs rerolling, please explain.
Thanks,
Michael
[1] http://permalink.gmane.org/gmane.comp.version-control.git/213672
[2] http://permalink.gmane.org/gmane.comp.version-control.git/213681
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Andreas Schwab @ 2013-01-18 15:02 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, felipe.contreras, git
In-Reply-To: <1358505065-16913-1-git-send-email-drafnel@gmail.com>
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.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: Yann Dirson @ 2013-01-18 14:37 UTC (permalink / raw)
To: greened; +Cc: git list
In-Reply-To: <877gnx39aa.fsf@waller.obbligato.org>
On Mon, 31 Dec 2012 20:51:41 -0600
greened@obbligato.org wrote:
> Yann Dirson <dirson@bertin.fr> writes:
>
> > 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?
>
> Specifying a local branch works fine, though, as does a raw commit
> hash. What do you mean by "local commit?"
With no <repository> arg documented, my understanding was that I should first
"git remote add" and fetch the repo in which the branch to be added as subtree
lived. This when running "git subtree add", the commit was indeed existing
locally.
> > 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").
>
> Seems to work for me. Can you give me the command you're using when you
> see the problem?
Hm, can't remember exactly how I reached that. But when experimenting to
reproduce:
$ contrib/subtree/git-subtree.sh add -P foo . origin/maint
git fetch . origin/maint
From .
* remote-tracking branch origin/maint -> FETCH_HEAD
Added dir 'foo'
=> OK
$ contrib/subtree/git-subtree.sh add -P fooo . origin/maint^0
git fetch . origin/maint^0
fatal: Invalid refspec 'origin/maint^0'
=> a commit is advertised, but in fact it seems to require a refspec
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: John Keeping @ 2013-01-18 10:32 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <CAGdFq_gew1-YmeUh=brWREHSYQvaV7vRBmEo0KFzi-ViqzOnaw@mail.gmail.com>
On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping <john@keeping.me.uk> wrote:
> > [1] http://wiki.python.org/moin/PortingPythonToPy3k
>
> This link seems dead.
Looks like the Python wiki is down [1].
I'll replace it with [2] since the content is similar and it should be
easier to find a mirror of the Python documentation than of the wiki.
[1] http://pyfound.blogspot.co.uk/2013/01/wikipythonorg-compromised.html
[2] http://docs.python.org/3.3/howto/pyporting.html#during-installation
John
^ permalink raw reply
* [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Brandon Casey @ 2013-01-18 10:31 UTC (permalink / raw)
To: gitster; +Cc: felipe.contreras, git, Brandon Casey
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>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..c14e329 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.8.1.1.252.gdb33759
^ permalink raw reply related
* RE: Question re. git remote repository
From: David Lang @ 2013-01-18 6:18 UTC (permalink / raw)
To: Matt Seitz
Cc: Lang, David, Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com>
On Fri, 18 Jan 2013, Matt Seitz wrote:
> From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]
>
> 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
I'm glad to learn that git is more robust than I feared.
David Lang
^ permalink raw reply
* RE: Question re. git remote repository
From: Matt Seitz @ 2013-01-18 5:51 UTC (permalink / raw)
To: Lang, David, David Lang
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <201301172153.r0HLrU4F019815@smtpb02.one-mail.on.ca>
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
^ permalink raw reply
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Torsten Bögershausen @ 2013-01-18 5:20 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jean-Noël AVILA, Torsten Bögershausen, Jeff King,
Junio C Hamano, git, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <20130118000454.GI13449@google.com>
On 18.01.13 01:04, Jonathan Nieder wrote:
> Jean-Noël AVILA wrote:
>
>> OK. I have installed practically everything related to git from the package
>> manager and there is a git-checkout-branches utility available.
>>
>> That result defeats the purpose of the test. This needs a tighter environment
>> to work whatever the configuration of the user may be.
> Presumably 'git checkout-branches' is from git-stuff.
>
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH. I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts? Maybe it would be enough to check that the intended get
> commands are present in the completion list and other git commands are
> not, ignoring binaries that might live elsewhere on the $PATH?
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> t/t9902-completion.sh | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 3cd53f8..06dcfb2 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -192,19 +192,19 @@ test_expect_success 'general options' '
> '
>
> test_expect_success 'general options plus command' '
> - test_completion "git --version check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --git-dir=foo check" "checkout " &&
> - test_completion "git --bare check" "checkout " &&
> - test_completion "git --help des" "describe " &&
> - test_completion "git --exec-path=foo check" "checkout " &&
> - test_completion "git --html-path check" "checkout " &&
> - test_completion "git --no-pager check" "checkout " &&
> - test_completion "git --work-tree=foo check" "checkout " &&
> - test_completion "git --namespace=foo check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --info-path check" "checkout " &&
> - test_completion "git --no-replace-objects check" "checkout "
> + test_completion "git --version cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --git-dir=foo cherry-p" "cherry-pick " &&
> + test_completion "git --bare cherry-p" "cherry-pick " &&
> + test_completion "git --help cherry-p" "cherry-pick " &&
> + test_completion "git --exec-path=foo cherry-p" "cherry-pick " &&
> + test_completion "git --html-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-pager cherry-p" "cherry-pick " &&
> + test_completion "git --work-tree=foo cherry-p" "cherry-pick " &&
> + test_completion "git --namespace=foo cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --info-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-replace-objects cherry-p" "cherry-pick "
> '
>
> test_expect_success 'setup for ref completion' '
That looks good to me, thanks.
^ 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