[PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
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 draf...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote: On Thu, Jan 17, 2013 at 10:53 AM, John Keeping j...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
Brandon Casey draf...@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, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jan 2013, #07; Thu, 17)
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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to convert a subversion repo to git
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9902 fails
Jonathan Nieder jrnie...@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;;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jan 2013, #07; Thu, 17)
Michael Haggerty mhag...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
On Thu, Jan 17, 2013 at 11:44 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT get corrupted on lustre
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-ow...@vger.kernel.org [mailto:git-ow...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
On Fri, Jan 18, 2013 at 9:15 AM, Phil Hord phil.h...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
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:mse...@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-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang, David [david.l...@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 (da...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to convert a subversion repo to git
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 g...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: merge vs. rebase question
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 d...@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 signature.asc Description: OpenPGP digital signature
Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
Brandon Casey draf...@gmail.com writes: On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab sch...@linux-m68k.org wrote: Brandon Casey draf...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
On Fri, Jan 18, 2013 at 11:08 AM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: On Fri, Jan 18, 2013 at 7:02 AM, Andreas Schwab sch...@linux-m68k.org wrote: Brandon Casey draf...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
On Fri, Jan 18, 2013 at 11:04:15AM -0800, Junio C Hamano wrote: John Keeping j...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9902 fails
Junio C Hamano gits...@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);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
David Lang da...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
On Fri, 18 Jan 2013, Junio C Hamano wrote: David Lang da...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
David Lang da...@lang.hm writes: On Fri, 18 Jan 2013, Junio C Hamano wrote: David Lang da...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote: John Keeping j...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9902 fails
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit : Junio C Hamano gits...@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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
John Keeping j...@keeping.me.uk writes: On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: As more people have started trying to support Python 3 in the wild, it has become clear that it is often easier to have a single codebase that works with both Python 2 and Python 3, and not use 2to3. It is for this reason that the Unicode literal prefix was reintroduced. Yes, and from that perspective, placing floor on earlier 3.x makes tons of sense, no? These early versions may not be unstable in the this does not behave as specified in the language specification for 3.x sense, but for the purpose of running scripts meant to be executable by both 2.x and 3.x series, the early 3.x versions are not as good as later versions where Python folks started making deliberate effort to support them. As far as I'm aware (and having reviewed the release notes for 3.1, 3.2 and 3.3 as well as the planned features for 3.4), Unicode literals are the only feature to have been added that was intended to make it easier to support Python 2 and 3 in the same codebase. So there may be some other incompatibility lurking that we may run into later? Given that no code currently on pu uses Unicode literals, I don't see a reason to specify a minimum version of Python 3 since we're already restricting ourselves to features in 2.6. OK, at least that reasoning need to be kept somewhere, either in the documentation of in the log message. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9902 fails
Jean-Noël AVILA avila...@gmail.com writes: Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit : Junio C Hamano gits...@pobox.com writes: How about doing something like this and set that variable in the test instead? If STD_ONLY is not set, you will get everything, but when STD_ONLY is set, we will stop reading from help -a when it starts listing additional stuff. I tried both of your propositions but none made test 10 of t9902 pass. Do you have a leftover git-check-ignore or something from a previous build that is *not* known to git you just built? Neither will help in such a case. The test pretty much runs with GIT_EXEC_PATH set to the build area, and we do want to be able to test what we have in the build area before we decide to install them, so that is nothing new. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9902 fails
Junio C Hamano gits...@pobox.com writes: Jean-Noël AVILA avila...@gmail.com writes: Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit : Junio C Hamano gits...@pobox.com writes: How about doing something like this and set that variable in the test instead? If STD_ONLY is not set, you will get everything, but when STD_ONLY is set, we will stop reading from help -a when it starts listing additional stuff. I tried both of your propositions but none made test 10 of t9902 pass. Do you have a leftover git-check-ignore or something from a previous build that is *not* known to git you just built? ... in the build directory was missing from the sentence. Sorry about noise. Neither will help in such a case. The test pretty much runs with GIT_EXEC_PATH set to the build area, and we do want to be able to test what we have in the build area before we decide to install them, so that is nothing new. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
On Fri, Jan 18, 2013 at 02:26:06PM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote: These early versions may not be unstable in the this does not behave as specified in the language specification for 3.x sense, but for the purpose of running scripts meant to be executable by both 2.x and 3.x series, the early 3.x versions are not as good as later versions where Python folks started making deliberate effort to support them. As far as I'm aware (and having reviewed the release notes for 3.1, 3.2 and 3.3 as well as the planned features for 3.4), Unicode literals are the only feature to have been added that was intended to make it easier to support Python 2 and 3 in the same codebase. So there may be some other incompatibility lurking that we may run into later? I doubt it - enough projects are running on Python 2 and 3 now that I doubt there's anything unexpected left to hit. Given that no code currently on pu uses Unicode literals, I don't see a reason to specify a minimum version of Python 3 since we're already restricting ourselves to features in 2.6. OK, at least that reasoning need to be kept somewhere, either in the documentation of in the log message. I'll put it in the log message when I send this as a proper patch. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
From: David Lang da...@lang.hm Sent: Friday, January 18, 2013 9:27 PM On Fri, 18 Jan 2013, Junio C Hamano wrote: David Lang da...@lang.hm writes: What I would do is to have each developer have their own local copy that they are working on. If you have a third machine to host the bare 'master' repo that would provide additional security/backup to touy local machines. [...] Junio, is there a really good place we should be pointing David where the different workflows are described and explained? `git help workflows` perhaps. Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement
Jeff King p...@peff.net writes:
When we advertise a ref, the first thing we do is parse the
pointed-to object. This gives us two things:
1. a struct object we can use to store flags
2. the type of the object, so we know whether we need to
dereference it as a tag
Instead, we can just use lookup_unknown_object to get an
object struct, and then fill in just the type field using
sha1_object_info (which, in the case of packed files, can
find the information without actually inflating the object
data).
This can save time if you have a large number of refs, and
the client isn't actually going to request those refs (e.g.,
because most of them are already up-to-date).
The downside is that we are no longer verifying objects that
we advertise by fully parsing them (however, we do still
know we actually have them, because sha1_object_info must
find them to get the type). While we might fail to detect a
corrupt object here, if the client actually fetches the
object, we will parse (and verify) it then.
...
This is an old news, but do you recall why this patch did not update
the code in mark_our_ref() that gets struct object *o from parse_object()
the same way and mark them with OUR_REF flag?
I was wondering about code consolidation like this.
upload-pack.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..609cd6c 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,18 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data);
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag,
void *cb_data)
{
static const char *capabilities = multi_ack thin-pack side-band
side-band-64k ofs-delta shallow no-progress
include-tag multi_ack_detailed;
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, %s %s%c%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
@@ -740,10 +743,6 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
else
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o-flags OUR_REF)) {
- o-flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, %s %s^{}\n, sha1_to_hex(peeled),
refname_nons);
return 0;
@@ -751,7 +750,7 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
{
- struct object *o = parse_object(sha1);
+ struct object *o = parse_object(sha1); /* lookup-unknown??? */
if (!o)
die(git upload-pack: cannot find object %s:,
sha1_to_hex(sha1));
if (!(o-flags OUR_REF)) {
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-svn: teach find-rev to find near matches
Eric Wong normalper...@yhbt.net writes: I've pushed this out to git://bogomips.org/git-svn along with a few other things I seem to have forgotten about :x John Keeping (1): git-svn: teach find-rev to find near matches Jonathan Nieder (2): Git::SVN::Editor::T: pass $deletions to -A and -D git svn: do not overescape URLs (fallback case) Thanks; pulled and pushed out. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Hiding some refs in ls-remote
This is an early preview of reducing the network cost while talking with a repository with tons of refs, most of which are of use by very narrow audiences (e.g. refs under Gerrit's refs/changes/ are useful only for people who are interested in the changes under review). As long as these narrow audiences have a way to learn the names of refs or objects pointed at by the refs out-of-band, it is not necessary to advertise these refs. On the server end, you tell upload-pack that some refs do not have to be advertised with the uploadPack.hiderefs multi-valued configuration variable: [uploadPack] hiderefs = refs/changes The changes necessary on the client side to allow fetching objects at the tip of a ref in hidden hierarchies are much more involved and not part of this early preview, but the end user UI is expected to be like these: $ git fetch $there refs/changes/72/41672/1 $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182 That is, you ask for a refname as usual even though it is not part of ls-remote response, or you ask for the commit object that is at the tip of whatever hidden ref you are interested in. Junio C Hamano (2): upload-pack: share more code upload-pack: allow hiding ref hiearchies t/t5512-ls-remote.sh | 9 ++ upload-pack.c| 86 ++-- 2 files changed, 79 insertions(+), 16 deletions(-) -- 1.8.1.1.454.g48d39c0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] upload-pack: share more code
We mark the objects pointed at our refs with OUR_REF flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
just like we did in 435c833 (upload-pack: use peel_ref for ref
advertisements, 2012-10-04).
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..3dd220d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,28 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
+{
+ struct object *o = lookup_unknown_object(sha1);
+ if (!o)
+ die(git upload-pack: cannot find object %s:,
sha1_to_hex(sha1));
+ if (!(o-flags OUR_REF)) {
+ o-flags |= OUR_REF;
+ nr_our_refs++;
+ }
+ return 0;
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag,
void *cb_data)
{
static const char *capabilities = multi_ack thin-pack side-band
side-band-64k ofs-delta shallow no-progress
include-tag multi_ack_detailed;
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, %s %s%c%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
@@ -740,27 +753,11 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
else
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o-flags OUR_REF)) {
- o-flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, %s %s^{}\n, sha1_to_hex(peeled),
refname_nons);
return 0;
}
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
-{
- struct object *o = parse_object(sha1);
- if (!o)
- die(git upload-pack: cannot find object %s:,
sha1_to_hex(sha1));
- if (!(o-flags OUR_REF)) {
- o-flags |= OUR_REF;
- nr_our_refs++;
- }
- return 0;
-}
-
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
--
1.8.1.1.454.g48d39c0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] upload-pack: allow hiding ref hiearchies
Teach upload-pack to omit some refs from the initial advertisement
by introducing the uploadPack.hiderefs multivalued configuration
variable. Any ref that is under the hierarchies listed on the value
of this variable is excluded from responses to ls-remote, fetch
or clone requests. One typical use case may be
[uploadPack]
hiderefs = refs/changes
Note that the underlying protocol allows a request to fetch objects
at the tip of any ref, including the hidden ones, but on the client
side (e.g. fetch-pack), the requests are checked against the
ls-remote response, so it cannot ask for refs/changes/72/41672/1, or
for the object name (which is what eventually goes over the wire on
want line) the user may obtain out of band (e.g. Gerrit
dashboard). A new capability allow-tip-sha1-in-want is returned
by upload-pack to signal updated clients that it may be OK to ask
for objects that were not advertised.
If we want to allow fetching refname that is hidden, e.g.
$ git fetch $there refs/changes/72/41672/1
we need to further update the server side to understand a message
that has the refname instead of object name on want line. The
necessary change to the server side to support that is not in this
step.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5512-ls-remote.sh | 9
upload-pack.c| 61 ++--
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index d16e5d3..9ee3d2a 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -126,4 +126,13 @@ test_expect_success 'Report match with --exit-code' '
test_cmp expect actual
'
+test_expect_success 'Hide some refs' '
+ test_config uploadPack.hiderefs refs/tags
+ git ls-remote . actual
+ test_unconfig uploadPack.hiderefs
+ git ls-remote . |
+ sed -e / refs\/tags\//d expect
+ test_cmp expect actual
+'
+
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 3dd220d..54c304d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -12,6 +12,7 @@
#include run-command.h
#include sigchain.h
#include version.h
+#include string-list.h
static const char upload_pack_usage[] = git upload-pack [--strict]
[--timeout=n] dir;
@@ -28,10 +29,13 @@ static const char upload_pack_usage[] = git upload-pack
[--strict] [--timeout=
static unsigned long oldest_have;
-static int multi_ack, nr_our_refs;
+static int multi_ack;
+static int nr_our_refs; /* This counts both advertised and unadvertised */
static int no_done;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
+static struct string_list *hide_refs;
+static int allow_tip_sha1_in_want;
static int shallow_nr;
static struct object_array have_obj;
static struct object_array want_obj;
@@ -722,6 +726,23 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int ref_is_hidden(const char *refname)
+{
+ struct string_list_item *item;
+
+ if (!hide_refs)
+ return 0;
+ for_each_string_list_item(item, hide_refs) {
+ int len;
+ if (prefixcmp(refname, item-string))
+ continue;
+ len = strlen(item-string);
+ if (!refname[len] || refname[len] == '/')
+ return 1;
+ }
+ return 0;
+}
+
static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
{
struct object *o = lookup_unknown_object(sha1);
@@ -743,11 +764,14 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
unsigned char peeled[20];
mark_our_ref(refname, sha1, flag, cb_data);
+ if (allow_tip_sha1_in_want ref_is_hidden(refname))
+ return 0;
if (capabilities)
- packet_write(1, %s %s%c%s%s agent=%s\n,
+ packet_write(1, %s %s%c%s%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
0, capabilities,
+allow_tip_sha1_in_want ? allow-tip-sha1-in-want
: ,
stateless_rpc ? no-done : ,
git_user_agent_sanitized());
else
@@ -758,11 +782,21 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
return 0;
}
+static int check_hidden_ref(const char *refname, const unsigned char *sha1,
int flag, void *cb_data)
+{
+ if (!ref_is_hidden(refname))
+ return 0;
+ allow_tip_sha1_in_want = 1;
+ return 1; /* terminate iteration over refs early */
+}
+
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
reset_timeout();
head_ref_namespaced(send_ref, NULL);
+ if (hide_refs)
+
Re: t9902 fails
On 18.01.13 23:23, Jean-Noël AVILA wrote: Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit : Junio C Hamano gits...@pobox.com writes: How about doing something like this and set that variable in the test instead? If STD_ONLY is not set, you will get everything, but when STD_ONLY is set, we will stop reading from help -a when it starts listing additional stuff. I tried both of your propositions but none made test 10 of t9902 pass. Am I supposed to run make install before running the test? No. The test suite could (and should) be run before you make install. So a typical sequence could be: Run test suite, and if that passes, install the binaries on my system. This could look like this on the command line: make test sudo make install Jean-Noël, would it be possible to run git status and share the result with us? And did you try Jonathans patch? /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Hiding some refs in ls-remote
On Sat, Jan 19, 2013 at 7:37 AM, Junio C Hamano gits...@pobox.com wrote: This is an early preview of reducing the network cost while talking with a repository with tons of refs, most of which are of use by very narrow audiences (e.g. refs under Gerrit's refs/changes/ are useful only for people who are interested in the changes under review). As long as these narrow audiences have a way to learn the names of refs or objects pointed at by the refs out-of-band, it is not necessary to advertise these refs. On the server end, you tell upload-pack that some refs do not have to be advertised with the uploadPack.hiderefs multi-valued configuration variable: [uploadPack] hiderefs = refs/changes The changes necessary on the client side to allow fetching objects at the tip of a ref in hidden hierarchies are much more involved and not part of this early preview, but the end user UI is expected to be like these: $ git fetch $there refs/changes/72/41672/1 $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182 That is, you ask for a refname as usual even though it is not part of ls-remote response, or you ask for the commit object that is at the tip of whatever hidden ref you are interested in. Should the client side learn how to list hidden refs too? I'm thinking of an extreme case where upload-pack advertises nothing (or maybe just refs/heads/master) and it's up to the client to ask for the ref selection it's interested in. upload-pack may need more updates to do that, I think. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOCBUG] git subtree synopsis needs updating
On 12-10-20, Herman van Rink wrote: On 10/19/2012 03:21 PM, Yann Dirson wrote: As the examples in git-subtree.txt show, the synopsis in the same file should surely get a patch along the lines of: -'git subtree' add -P prefix commit +'git subtree' add -P prefix repository commit Failure to specify the repository (by just specifying a local commit) fails with the cryptic: warning: read-tree: emptying the index with no arguments is deprecated; use --empty fatal: just how do you expect me to merge 0 trees? Furthermore, the doc paragraph for add, aside from mentionning repository, also mentions a refspec which the synopsis does not show either. As a sidenote it someone wants to do some maintainance, using . as repository when the branch to subtree-add is already locally available does not work well either (fails with could not find ref myremote/myhead). The version of subtree in contrib is rather out-dated unfortunately. You should really submit these patches here for reviewing, David is actively maintaining this tool here. I've collected a bunch of patches in https://github.com/helmo/git/tree/subtree-updates The documentation issue is also fixed in there. -- Met vriendelijke groet / Regards, Herman van Rink Initfour websolutions -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Hiding some refs in ls-remote
On 01/19/2013 01:37 AM, Junio C Hamano wrote: This is an early preview of reducing the network cost while talking with a repository with tons of refs, most of which are of use by very narrow audiences (e.g. refs under Gerrit's refs/changes/ are useful only for people who are interested in the changes under review). As long as these narrow audiences have a way to learn the names of refs or objects pointed at by the refs out-of-band, it is not necessary to advertise these refs. On the server end, you tell upload-pack that some refs do not have to be advertised with the uploadPack.hiderefs multi-valued configuration variable: [uploadPack] hiderefs = refs/changes The changes necessary on the client side to allow fetching objects at the tip of a ref in hidden hierarchies are much more involved and not part of this early preview, but the end user UI is expected to be like these: $ git fetch $there refs/changes/72/41672/1 $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182 That is, you ask for a refname as usual even though it is not part of ls-remote response, or you ask for the commit object that is at the tip of whatever hidden ref you are interested in. Although I can understand the pain of slow network performance, somehow this proposal gives me the feeling of being expeditious rather than elegant. Could the problem be solved in some other way? Maybe such references could be stored in a second repository or in a separate namespace (in the sense of gitnamespaces(7)) to prevent their creating overhead when they are unneeded? And *if* reference hiding makes sense, it seems to me that the client, not the server, should be the one who decides which server references it is interested in (though I understand that would require a protocol change). Otherwise the git repository *relies* on out-of-band channels for its functionality. If I understand correctly, a user would have *no way* to discover, via git, what hidden references are contained in a remote repository, or indeed even that the repo contains a hidden namespace. For example this would make it impossible to clean up obsolete hidden references on a remote repository without the supplementary information stored elsewhere. And if anybody accidentally creates a reference in a hidden namespace by hand, it will just sit there undetectably, forever. I assume (though I've never checked) that a server does not let a client ask for a SHA1 that is not currently reachable from a server-side reference, and I assume that that you are not proposing to change this policy. But allowing objects to be fetched from a hidden reference opens up some interesting possibilities: * A pusher could upload arbitrary content to a public git server under a cryptic hidden reference name. Most people would be completely unable to see this content, unless given the SHA1 or the reference name by the pusher. Thus this mechanism could be used as a dark channel to exchange arbitrary data relatively secretly. * Somebody could push a trojan version of code to a hidden reference in a project, then pass the SHA1 to a victim. The victim might trust the code because it comes from a known project website, even though the code would be invisible to other project developers and thus impossible for them to audit. And even if they learned about the trojan's SHA1 they would be unable to remove it from their repository because they have no way to find out the name of the hidden reference! Obviously these hacks would only be possible for a bad guy with push privileges to a repository that has turned on hidden references, but I think they are sobering nevertheless. These worries would go away if reference hiding were configured on the client rather than on the server. A second point: currently, the output of git show-ref -d and git ls-remote . are almost identical. Under your proposal, I believe that the hiderefs would only be omitted from the latter. Would it be useful to add an option to git show-ref to make it omit the hiderefs refs? And maybe another option to make it display *only* the hideref refs? And in the bikeshedding department, I wonder if hiderefs is the best name for the config setting. hiderefs, implies to me that the refs are actively hidden and not available to the client in any way. But in fact they are just not advertised; they can be fetched normally. Maybe another name would be more suggestive of its true effect, for example quietrefs or noadvertiserefs. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] t0050: known breakage vanished in merge (case change)
This test case has passed ever since: commit 0047dd2fd1fc1980913901c5fa098357482c2842 Author: Steffen Prohaska proha...@zib.de Date: Thu May 15 07:19:54 2008 +0200 t0050: Fix merge test on case sensitive file systems Demand it to pass by using test_expect_success Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t0050-filesystem.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index 78816d9..ccd685d 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -77,7 +77,7 @@ $test_case 'rename (case change)' ' ' -$test_case 'merge (case change)' ' +test_expect_success 'merge (case change)' ' rm -f CamelCase rm -f camelcase -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)
The test case add (with different case) indicates a known breakage when run on a case sensitive file system. The test is invalid for case sensitive file system, check the precondition CASE_INSENSITIVE_FS before running it. Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t0050-filesystem.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index ccd685d..a6fa3c5 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -88,7 +88,7 @@ test_expect_success 'merge (case change)' ' -test_expect_failure 'add (with different case)' ' +test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' git reset --hard initial rm camelcase -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] t0050: Use TAB for indentation
Use one TAB for indentation and remove empty lines Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t0050-filesystem.sh | 48 +++- 1 file changed, 15 insertions(+), 33 deletions(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index a6fa3c5..05d78d2 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -29,12 +29,10 @@ test_have_prereq SYMLINKS || if test_have_prereq CASE_INSENSITIVE_FS then test_expect_success detection of case insensitive filesystem during repo init ' - test $(git config --bool core.ignorecase) = true ' else test_expect_success detection of case insensitive filesystem during repo init ' - test_must_fail git config --bool core.ignorecase /dev/null || test $(git config --bool core.ignorecase) = false ' @@ -43,20 +41,17 @@ fi if test_have_prereq SYMLINKS then test_expect_success detection of filesystem w/o symlink support during repo init ' - test_must_fail git config --bool core.symlinks || test $(git config --bool core.symlinks) = true ' else test_expect_success detection of filesystem w/o symlink support during repo init ' - v=$(git config --bool core.symlinks) test $v = false ' fi test_expect_success setup case tests ' - git config core.ignorecase true touch camelcase git add camelcase @@ -67,29 +62,23 @@ test_expect_success setup case tests ' git mv tmp CamelCase git commit -m rename git checkout -f master - ' $test_case 'rename (case change)' ' - git mv camelcase CamelCase git commit -m rename - ' test_expect_success 'merge (case change)' ' - rm -f CamelCase rm -f camelcase git reset --hard initial git merge topic - ' test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' - git reset --hard initial rm camelcase echo 1 CamelCase @@ -97,37 +86,30 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' camel=$(git ls-files | grep -i camelcase) test $(echo $camel | wc -l) = 1 test z$(git cat-file blob :$camel) = z1 - ' test_expect_success setup unicode normalization tests ' - - test_create_repo unicode - cd unicode - touch $aumlcdiar - git add $aumlcdiar - git commit -m initial - git tag initial - git checkout -b topic - git mv $aumlcdiar tmp - git mv tmp $auml - git commit -m rename - git checkout -f master - + test_create_repo unicode + cd unicode + touch $aumlcdiar + git add $aumlcdiar + git commit -m initial + git tag initial + git checkout -b topic + git mv $aumlcdiar tmp + git mv tmp $auml + git commit -m rename + git checkout -f master ' $test_unicode 'rename (silent unicode normalization)' ' - - git mv $aumlcdiar $auml - git commit -m rename - + git mv $aumlcdiar $auml + git commit -m rename ' $test_unicode 'merge (silent unicode normalization)' ' - - git reset --hard initial - git merge topic - + git reset --hard initial + git merge topic ' test_done -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re* t9902 fails
Torsten Bögershausen tbo...@web.de writes:
would it be possible to run
git status
and share the result with us?
And did you try Jonathans patch?
It may hide the immediate issue, but I am afraid Jonathan's patch
does not fix anything fundamental. If you do this:
git checkout next
make
git checkout master ;# without 'make clean'
make cd t sh ./t9902-*.sh
then the completion machinery will see the leftover git-check-ignore
at the top of the working tree (which is the $GIT_EXEC_PATH) and the
test that expects check to expand only to checkout will fail,
because 'master' does not have exclusion definition for check-ignore,
even though it knows check-attr, check-ref-format and checkout-index
are to be excluded as plumbing.
So if you come up with a brilliant idea to add git cherry-pack
command and did this:
git checkout -b tb/cherry-pack
edit Makefile builtin/cherry-pack.c builtin.h git.c ...
git add builtin/cherry-pack.c
make test
git commit -a -m cherry-pack: new command
git checkout master ;# without 'make clean'
make cd t sh ./t9902-*.sh
the test will break exactly the same way.
If we really wanted to exclude random build artifacts that the
current checkout did not build, you have to do one of these things:
(1) at the beginning of t9902, rm -fr a temporary location,
install the built product with a custom DESTDIR set to that
temporary location that we now know is empty, and point
GIT_EXEC_PATH to the libexec/git-core directory in that
temporary location, so that git help -a run in the completion
script will find _only_ the executable we would install; or
(2) instead of being inclusive, collecting all executable in
GIT_EXEC_PATH that happens to be named git-, add a mode to
git help that lists those that we know to be standard
commands that the users may want to complete from the command
line.
An outline to do (2) would look like this patch, but I didn't check
other consumers of command-list.txt, so this may be breaking them in
unplanned ways.
builtin/help.c | 35 ++---
command-list.txt | 4 +--
contrib/completion/git-completion.bash | 14 +-
generate-cmdlist.sh| 13 +-
help.c | 47 --
help.h | 1 +
6 files changed, 75 insertions(+), 39 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index bd86253..32e7d64 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -6,7 +6,6 @@
#include cache.h
#include builtin.h
#include exec_cmd.h
-#include common-cmds.h
#include parse-options.h
#include run-command.h
#include column.h
@@ -36,11 +35,16 @@ enum help_format {
static const char *html_path;
-static int show_all = 0;
+#define HELP_SHOW_ALL 1
+#define HELP_SHOW_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_SHOW_ALL),
+ OPT_SET_INT(0, standard, show_what, N_(print all available
commands),
+ HELP_SHOW_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),
@@ -287,23 +291,6 @@ static int git_help_config(const char *var, const char
*value, void *cb)
static struct cmdnames main_cmds, other_cmds;
-void list_common_cmds_help(void)
-{
- int i, longest = 0;
-
- for (i = 0; i ARRAY_SIZE(common_cmds); i++) {
- if (longest strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts(_(The most commonly used git commands are:));
- for (i = 0; i ARRAY_SIZE(common_cmds); i++) {
- printf( %s , common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(_(common_cmds[i].help));
- }
-}
-
static int is_git_command(const char *s)
{
return is_in_cmdlist(main_cmds, s) ||
@@ -442,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char
*prefix)
builtin_help_usage, 0);
parsed_help_format = help_format;
- if (show_all) {
+ if (show_what == HELP_SHOW_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;
+ } else if (show_what == HELP_SHOW_STANDARD) {
+
Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
Assuming you tried this out on both 2.x and 3.x: Acked-by: Sverre Rabbelier srabbel...@gmail.com On Fri, Jan 18, 2013 at 2:32 AM, John Keeping j...@keeping.me.uk wrote: On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote: On Thu, Jan 17, 2013 at 10:53 AM, John Keeping j...@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 -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
