Read my offer
Please read my bleow email for a transfer offer of 6.5 Million Euro -- 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] completion: Support exclude prefix, ^rev
When using the exclude pattern, ^rev, the completion did not work.
This enables completion after ^ in the same way that completion after ..
is done.
Signed-off-by: Trygve Aaberge trygv...@gmail.com
---
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 8cfee95..3036dac 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -496,6 +496,10 @@ __git_complete_revlist_file ()
cur_=${cur_#*..}
__gitcomp_nl $(__git_refs) $pfx $cur_
;;
+ ^*)
+ cur_=${cur_#^}
+ __gitcomp_nl $(__git_refs) ^ $cur_
+ ;;
*)
__gitcomp_nl $(__git_refs)
;;
--
2.2.2
--
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
CTRL+Arrow keys don't work with Git Bash for Windows?
Hello, I'm trying to set up some navigation shortcuts I have become accustomed to using in Windows environments, as well as KDE Konsole. I would like to bind CTRL+Left to backward-word and CTRL+Right to forward-word (there are more, but this is a start). I can enable this behavior by adding something like \e[D: forward-word to my ./inputrc file, but this also overwrites the forward-char sequence that comes from a Right Arrow press without the CTRL key. For some reason, when I use the Git Bash shell the key sequence for CTRL+Right and Right (\e[C) are the same -- same with CTRL+Left and Left (\e[D). Most of the solutions I have come across only address adding things to the .inputrc file, but in this case that is not the problem. The problem is that the CTRL+Arrow keys are not sending any unique sequences. These sequences are distinct and can be bound as I am describing when using the mintty.exe xterm terminal emulator. So why are they not working when I start up Git Bash (which I believe has no emulator, it just uses windows cmd.exe?). I also see this problem when I use the bash.exe --login -l that was installed with MinGW/MSys. Thanks for any suggestions on how to enable this behavior. Kevin -- 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 loses commits on git pull --rebase with Dictator and Lieutenants Workflow
Hi, On Thu, Jan 29, 2015 at 8:49 AM, Dick d...@mrns.nl wrote: Hi all, I've encountered a problem with the Dictator and Lieutenants Workflow. I've configured remote origin so it pulls from the blessed repository and pushes to the developer public repository. When the blessed repository has the same branch name as the developer public repository git pull seems to drop commits. I've create a test script to demonstrate, left is the blessed repository, right.git is the developer public and right is the developer private repository. rm -rf left/ right/ right.git/ git init left cd left/ echo hello world test.txt git add test.txt git commit -m . cd .. git clone --bare left right.git git clone right.git/ right cd right git remote set-url origin ../left git remote set-url origin --push ../right.git echo bye world test.txt git commit -a -m . git push git log echo start: two commits, ok git fetch git rebase origin/master git log echo manual fetch/rebase: two commits, still ok git pull --rebase git log echo pull: one commits, oops? Am I using git wrong or is this a git bug? Thanks for having a look! Dick I can confirm the behaviour that Dick is seeing with git 2.0.4 (happens to be what I was running on my laptop). Just rebuilding 2.3.0-rc2 now. AFAIK 'git fetch git rebase origin/master' and 'git pull -r' in the scenario above should be roughly equivalent. I'll see if I can work the testcase above into an actual test script. -- 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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 29/01/15 16:43, Jeff King wrote: Weird. The pubkeys are there in keyring.gpg; I wonder why the older version of gpg has trouble extracting them (and how one was _supposed_ to export secret keys at that time). Importing the unmodified keyring.gpg with 1.2.6 yields this: $ gpg --homedir $GNUPGHOME --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: Total number processed: 2 gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir $GNUPGHOME --list-keys $ gpg --homedir $GNUPGHOME --list-secret-keys /home/tgc/gpghome/secring.gpg - sec 1024D/CDDE430D 2007-06-07 C O Mitter commit...@example.com ssb 2048g/7703B0E5 2007-06-07 sec 2048R/B7227189 2013-03-22 Eris Discordia disc...@example.net ssb 2048R/29472784 2013-03-22 $ So if I understand you correctly, the tests should pass with the patch below? Yes, adding the pubkeys as a separate entity makes gpg 1.2.6 understand things fine. gnupg 1.2.6 with the patched keyring: $ gpg --homedir $GNUPGHOME --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key C O Mitter commit...@example.com imported gpg: key B7227189: public key Eris Discordia disc...@example.net imported gpg: Total number processed: 4 gpg: imported: 2 (RSA: 1) gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir $GNUPGHOME --list-keys /home/tgc/gpghome/pubring.gpg - pub 1024D/CDDE430D 2007-06-07 C O Mitter commit...@example.com sub 2048g/7703B0E5 2007-06-07 pub 2048R/B7227189 2013-03-22 Eris Discordia disc...@example.net sub 2048R/29472784 2013-03-22 $ The patch should work as posted, though I have only tested the new keyring by hand as shown above. It feels a bit hacky, and I wish I knew more about why the current file doesn't work (i.e., if we did gpg --export-secret-keys with v1.2.6, would it produce different output that can be read by both versions?). I grabbed the binary keyrings from 1e3eefb^ and pointed gpg 1.2.6 at them. $ gpg --homedir $GNUPGHOME --armor --export-secret-keys CDDE430D CDDE430D.secret.key $ gpg --homedir $PWD/gpghome3 --import CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome3/secring.gpg' created gpg: keyring `/home/tgc/gpghome3/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir $PWD/gpghome3 --list-keys $ No public key imported however the pubkey *was* exported to CDDE430D.secret.key Importing that same keyfile using gnupg 1.4.5 on an RHEL5 host: $ gpg --homedir $PWD/gpghome --import /tmp/CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key C O Mitter commit...@example.com imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir /home/tgc/gpghome --list-keys /home/tgc/gpghome/pubring.gpg - pub 1024D/CDDE430D 2007-06-07 uid C O Mitter commit...@example.com sub 2048g/7703B0E5 2007-06-07 $ So gnupg 1.2.6 can export fine but cannot correctly import the same. Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). That would seem a bit heavy-handed as it is otherwise working fine with the old gnupg. snip patch -tgc -- Tom G. Christensen - Systemmedarbejder - IT-drift Statsbiblioteket - Victor Albecks Vej 1 - 8000 Aarhus C Tlf: (+45) 8946 2027 - Fax: (+45) 8946 2029 CVR/SE: 10100682 - EAN: 5798000791084 -- 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
our 36 SCI/ISI indexed journals will be available to you to publish the extended version of your papers.
Dear Prof. This email acts as an invitation to our March 15-17, 2015 conferences in Austria, Vienna. Along with the conference proceedings book, CD and E-library, as an invited participant, our 36 SCI/ISI indexed journals will be available to you to publish the extended version of your papers. In order to submit your paper to the conference, please visit our site at www [dot] inase [dot] org, select the conference that applies to you, and use the official submission platform found on the conference page. Presentation time for all invited speakers is 30 minutes, as opposed to the usual 15 minutes. As an invited presenter, your paper will show up as accordingly in the conference program, and you will be member of the scientific committee next year. Sincerely yours Dr. Yana Petrova * If you do not want to be invited again, send an email to info @ inase. org with Subject: DO NOT INVITED ME AGAIN git@vger.kernel.org -- 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
All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 28/01/15 00:35, Junio C Hamano wrote: A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. All signed commit tests fail on RHEL4 which is a regression from 2.2.2. From t4202.42: ++ git tag -s -m signed_tag_msg signed_tag gpg: key CDDE430D: secret key without public key - skipped gpg: skipped `C O Mitter commit...@example.com': secret key not available gpg: signing failed: secret key not available error: gpg failed to sign the data error: unable to sign the tag error: last command exited with $?=128 There are indeed no public keys available after commit 1e3eef which seems to be contrary to the commit log: Instead import public and secret keys for one key pair from a text file that holds ASCII-armored export of them. I extracted the pubkeys as ascii armored text from the old binary keyrings and added them to the new keyring.gpg and then the tests pass. This is apparently only a problem for older gnupg versions (RHEL4 has gnupg 1.2.6) since it did not fail on RHEL5 (gnupg 1.4.5). -tgc -- 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
Broken makefile check for curl version on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 28/01/15 00:35, Junio C Hamano wrote:
A release candidate Git v2.3.0-rc2 is now available for testing
at the usual places.
Building is broken on RHEL4 which is a regression from 2.2.2.
The makefile check for curl = 7.34.0 fails and enables
USE_CURL_FOR_IMAP_SEND even though curl is 7.12.1.
# curl-config --vernum
70C01
# { echo 072200; curl-config --vernum 2/dev/null ; } | sort -r | sed -ne 2p
072200
#
I checked the curl release tarballs and this problem seems to exist for
curl 7.11.0 (0x70B00) through 7.12.2 (0x70C02). In both 7.10.7
(0x070a07) and 7.12.3 (0x070c03) the version is correctly set using 6
hex digits as documented.
I tried to verify this using the official curl repo on github but it
does not seem to record this discrepancy and shows the correct 6 digit
version numbers for the affected releases.
As a workaround I'm piping curl-config --vernum through sed -e
'/^70[B-C]/ s/^7/07/'.
-tgc
--
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
Testsuite regression with perl 5.8.0 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 28/01/15 00:35, Junio C Hamano wrote: A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. Commit 2cf770 added testing of the --[no-]xmailer option to git send-email in t9001-send-email.sh Unfortunately it used the modern Getopt::long style of --no-option to negate the option which is not supported with Getopt::Long 2.32 as shipped with perl 5.8.0 on RHEL3 causing the tests to fail. Changing the --no-xmailer option to the old --noxmailer style allows the tests to pass. -tgc -- 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 loses commits on git pull --rebase with Dictator and Lieutenants Workflow
On Fri, Jan 30, 2015 at 6:27 AM, Chris Packham judge.pack...@gmail.com wrote: Hi, On Thu, Jan 29, 2015 at 8:49 AM, Dick d...@mrns.nl wrote: Hi all, I've encountered a problem with the Dictator and Lieutenants Workflow. I've configured remote origin so it pulls from the blessed repository and pushes to the developer public repository. When the blessed repository has the same branch name as the developer public repository git pull seems to drop commits. I've create a test script to demonstrate, left is the blessed repository, right.git is the developer public and right is the developer private repository. rm -rf left/ right/ right.git/ git init left cd left/ echo hello world test.txt git add test.txt git commit -m . cd .. git clone --bare left right.git git clone right.git/ right cd right git remote set-url origin ../left git remote set-url origin --push ../right.git echo bye world test.txt git commit -a -m . git push git log echo start: two commits, ok git fetch git rebase origin/master git log echo manual fetch/rebase: two commits, still ok git pull --rebase git log echo pull: one commits, oops? Am I using git wrong or is this a git bug? Thanks for having a look! Dick I can confirm the behaviour that Dick is seeing with git 2.0.4 (happens to be what I was running on my laptop). Just rebuilding 2.3.0-rc2 now. Also happens on 2.3.0-rc2 AFAIK 'git fetch git rebase origin/master' and 'git pull -r' in the scenario above should be roughly equivalent. I'll see if I can work the testcase above into an actual test script. -- 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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 02:11:05PM +0100, Tom G. Christensen wrote: All signed commit tests fail on RHEL4 which is a regression from 2.2.2. From t4202.42: ++ git tag -s -m signed_tag_msg signed_tag gpg: key CDDE430D: secret key without public key - skipped gpg: skipped `C O Mitter commit...@example.com': secret key not available gpg: signing failed: secret key not available error: gpg failed to sign the data error: unable to sign the tag error: last command exited with $?=128 There are indeed no public keys available after commit 1e3eef which seems to be contrary to the commit log: Instead import public and secret keys for one key pair from a text file that holds ASCII-armored export of them. I extracted the pubkeys as ascii armored text from the old binary keyrings and added them to the new keyring.gpg and then the tests pass. This is apparently only a problem for older gnupg versions (RHEL4 has gnupg 1.2.6) since it did not fail on RHEL5 (gnupg 1.4.5). Weird. The pubkeys are there in keyring.gpg; I wonder why the older version of gpg has trouble extracting them (and how one was _supposed_ to export secret keys at that time). So if I understand you correctly, the tests should pass with the patch below? It feels a bit hacky, and I wish I knew more about why the current file doesn't work (i.e., if we did gpg --export-secret-keys with v1.2.6, would it produce different output that can be read by both versions?). Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). -- 8 -- Subject: [PATCH] t/lib-gpg: include separate public keys in keyring.gpg Since 1e3eefb (tests: replace binary GPG keyrings with ASCII-armored keys, 2014-12-12), we import our test GPG keys from a single file. Each keypair in the import stream contains both the secret and public keys. However, older versions of gpg reportedly fail to import the public half of the key. We can solve this by including duplicates of the public keys separately. The duplicates are ignored by modern gpg, and this makes older versions work. Reported by Tom G. Christensen t...@statsbiblioteket.dk on gpg 1.2.6 (from RHEL4). Signed-off-by: Jeff King p...@peff.net --- t/lib-gpg.sh | 2 ++ t/lib-gpg/keyring.gpg | 54 +++ 2 files changed, 56 insertions(+) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index d88da29..16e0d3f 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -23,6 +23,8 @@ else # To write armored exported key to keyring: # gpg --homedir /tmp/gpghome --export-secret-keys \ # --armor 0xDEADBEEF lib-gpg/keyring.gpg + # gpg --homedir /tmp/gpghome --export \ + # --armor 0xDEADBEEF lib-gpg/keyring.gpg # To export ownertrust: # gpg --homedir /tmp/gpghome --export-ownertrust \ #lib-gpg/ownertrust diff --git a/t/lib-gpg/keyring.gpg b/t/lib-gpg/keyring.gpg index fb1f048..d4754a1 100644 --- a/t/lib-gpg/keyring.gpg +++ b/t/lib-gpg/keyring.gpg @@ -86,3 +86,57 @@ Z9Ei+zj6JD5Pcdi3BJhQo9WOLOVEJ0NHmewTYqk9QVXH/0v1Hdl4LMJtgcbdbDWk BOW78WUxzhu0YJTLKy+iKCjg5HS5dx6OC+e4aEEgfhNPCMkbvDsJjtQ= =hieJ -END PGP PRIVATE KEY BLOCK- +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1 + +mQGiBEZnyykRBACzCPjIpTYNL7Y2tQqlEGTTDlvZcWNLjF5f7ZzuyOqNOidLUgFD +36qch1LZLSZkShdR3Gae+bsolyjxrlFuFP0eXRPMtqK20aLw7WZvPFpEV1ThMne+ +PRJjYrvghWw3L0VVIAIZ8GXwrVBuU99uEjHEI0ojYloOvFc2jVPgSaoBvwCg48Tj +fol2foSoJa7XUu9yAL8szg8D/RUsTzNF+I9hSRHl7MYKFMYoKEY9BDgrgAujp7YY +8qdGsiUb0Ggyzp2kRjZFt4lpcvKhGfHn5GEjmtk+fRbD5qPfMqKFW+T0NPfYlYmL +JJ4fs4qZ8Lx7x6iG6X51u+YNwsQuIGjMCC3CeNi3F7or651kkNYASbaQ1NROkCIN +NudyA/0aasvoZUoNJAc2cP5Ifs6WhXMWLfMR2p2XbfKwKNYneec60usnSComcKqh +sJVk0Gytvr3FOYVhRkXnKAbx+0W2urFP8OFVBTEKO6Ts2VygWGgneQYoHnqzwlUE +yjOjlr+lyf7u2s/KAxpKA6jnttEdRZAmzWkhuox1wwAUkr27/bQiQyBPIE1pdHRl +ciA8Y29tbWl0dGVyQGV4YW1wbGUuY29tPoheBBMRAgAeBQJGZ8spAhsDBgsJCAcD +AgMVAgMDFgIBAh4BAheAAAoJEBO29R7N3kMNdB0AoL3Z/7A6tORuY8R/676oD8a/ +oHFDAJ9DXbwlcKLcykwHy0jYqajXm1iCebkCDQRGZ8tOEAgAzrl5P1Pr6CDR8mf5 +DGGzcUUM+PEroA4FLdKJ5ZaZc7qy1lmmW9vuvb6xdinwcwee2c5fdNE+iUjHV2x2 +S/dbfDzJTN/0uajZcw+xnf+KxZ0Rs4gDSs7cHXHBtA7u8ShYd4Hu7JggXpiwgfSk +yrGQiZyLAHW2ck8H07Go8eUP8fLIeva+iPqeYQZo9BaPz92R/J6debpeY1lRkv+y +WTq1GE3C/hxbdBAuHf2duLP2uq9kwoVdfzCRjgV1CQmMIbCrMb7vIlzIe96bb3+K +r/+NEtmB2I3wHBXcwJMnIOnz9Zv933KNlxSbVF23BGLB+F9D7OanKymbs7Eg18fr +mt/t/wAEDQgAtGIxGz944Pn2OtheY9JlBRuIAuVskm24/Zz03dZnk6CuEOIBb5IM +g36GAPKcn1vsLZ0TfE1q53jNpcAAXjgngnRsCjZm1mglqPD4ZfBpl+Hhnuc80fAR +xsUPj+5c8KP2M+Rws4moaZRjVpd3KCi3ceflT/OjwnE9DzdhslCGTMA5n8cajAs2 +oqAaQssefVf2prLQLGV9NB4Q3lFnKXdvipHMaAYAsW+iF7JkhTDVNuNGlufeSqUm +igRBjTZXBcVd8sj8vDOCWKUfqxJyS+zRYcotn7QvpvcKAkc3ZGxntDHAIGLVp6ay
Re: Testsuite regression with perl 5.8.0 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 02:30:57PM +0100, Tom G. Christensen wrote: On 28/01/15 00:35, Junio C Hamano wrote: A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. Commit 2cf770 added testing of the --[no-]xmailer option to git send-email in t9001-send-email.sh Unfortunately it used the modern Getopt::long style of --no-option to negate the option which is not supported with Getopt::Long 2.32 as shipped with perl 5.8.0 on RHEL3 causing the tests to fail. Changing the --no-xmailer option to the old --noxmailer style allows the tests to pass. Both this and the curl-version issue you reported seem to have simple solutions that you've already worked out and tested. Would you like to express them in the form of patches so they can be applied? :) -Peff -- 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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 10:43:20AM -0500, Jeff King wrote:
It feels a bit hacky, and I wish I knew more about why the current file
doesn't work (i.e., if we did gpg --export-secret-keys with v1.2.6,
would it produce different output that can be read by both versions?).
Another option is to just declare that version old and broken, and skip
the tests (either by checking its version, or just checking after we
import the keys that we can actually _use_ them).
That would look like this:
-- 8 --
Subject: [PATCH] t/lib-gpg: sanity-check that we can actually sign
Some older versions of gpg (reportedly v1.2.6 from RHEL4)
cannot import the keyrings found in our test suite, and thus
cannot even make a signature. We can detect this case by
doing a test-sign before declaring the GPG prerequisite
fulfilled.
Signed-off-by: Jeff King p...@peff.net
---
t/lib-gpg.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index d88da29..a87747a 100755
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -34,6 +34,8 @@ else
$TEST_DIRECTORY/lib-gpg/keyring.gpg
gpg --homedir ${GNUPGHOME} 2/dev/null --import-ownertrust \
$TEST_DIRECTORY/lib-gpg/ownertrust
+ gpg --homedir ${GNUPGHOME} /dev/null /dev/null 21 \
+ --sign -u commit...@example.com
test_set_prereq GPG
;;
esac
--
2.3.0.rc1.287.g761fd19
--
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: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
Tom G. Christensen t...@statsbiblioteket.dk writes: On 29/01/15 16:43, Jeff King wrote: Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). That would seem a bit heavy-handed as it is otherwise working fine with the old gnupg. Thanks, both, for tracking this one down. I am tempted to say that we should do both. This export public key, even though new importers do not need fix to make things usable with 1.2.6, and the other one to catch and skip breakages when future versions of GPG breaks us in whichever way we do not anticipate now. -- 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 loses commits on git pull --rebase with Dictator and Lieutenants Workflow
Dick d...@mrns.nl writes: rm -rf left/ right/ right.git/ git init left cd left/ echo hello world test.txt git add test.txt git commit -m . cd .. git clone --bare left right.git git clone right.git/ right cd right git remote set-url origin ../left git remote set-url origin --push ../right.git This is not using origin and set-url correctly. Even though you can use physically different URLs for fetching from and pushing into, the named repository 'origin' is still conceptually the same repository. You use this mechanism when you want to fetch over the public git:// protocol (which is lighter-weight) while pushing into the same repository over ssh:// protocol (which may be heavier and requires authentication). The important part of the equation is that the data should go to and come from the same place. What you pushed to 'origin', if you fetch from 'origin' again, should come back to you. And that is not what your two calls to set-url are doing. In a triangular workflow to fetch from somewhere while pushing into somewhere else, you are using _two_ different repositories: your upstream's repository you fetch from, and your own repository you push to publish your result. So you would use _two_ remotes, not a single 'origin'. The 'right' person, who follows the 'left' developer who publishes the more authoritative work in 'left.git' for you and others to fetch from, and publishes his work to 'right.git' to ask 'left' to pull, would do something like: git init --bare right.git git clone left right cd right git remote add mine ../right.git git config remote.pushDefault mine git push --all;# to publish to ../right.git to set things up. Then edit git commit git other-commands ... git push ;# updates ../right.git to publish his work. Updating from 'left' would go like this: # pretend 'left' did something ( cd ../left git commit --allow-empty -m empty ) git pull ;# or 'git pull --rebase' -- 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 loses commits on git pull --rebase with Dictator and Lieutenants Workflow
Thanks Junio! I should use git config remote.pushDefault thanks for pointing me in the right direction. I guess the git remote set-url --push command should contain some warning about this. gr Dick -- 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
git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Hi, Looks like there might be a bug in SVN import code. Here is the command that fails git svn clone --username anonymous svn://powhegbox.mib.infn.it/trunk/POWHEG-BOX r217 = 2e6cdb1f4604b2256195590fa8275632971eac42 (refs/remotes/git-svn) M lhefread.f M Z_plus_jet/Born.f M Z_plus_jet/powheg.input M Z_plus_jet/init_processes.f D JJ/madgraph_3_flavours/born/nexternal.inc write .git/Git_svn_hash_bl5Cj3: Bad file descriptor at /usr/lib/perl5/vendor_perl/5.20.1/x86_64-linux-thread-multi/SVN/Ra.pm line 623. Tested on: git-svn version 2.3.0.rc2 (svn 1.8.11) - FAIL git-svn version 2.2.2 (svn 1.8.10) - FAIL git-svn version 1.8.4.5 (svn 1.8.11) - WORKS PS unfortunately I don't have admin access to SVN repository With best regards, Valery Yundin. -- 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] apply: refuse touching a file beyond symlink
Because Git tracks symbolic links as symbolic links, a path that has
a symbolic link in its leading part (e.g. path/to/dir/file, where
path/to/dir is a symbolic link to somewhere else, be it inside or
outside the working tree) can never appear in a patch that validly
applies, unless the same patch first removes the symbolic link to
allow a directory to be there.
Detect and reject such a patch. Things to note:
- Unfortunately, we cannot reuse the has_symlink_leading_path()
from dir.c, as that is only about the working tree, but git
apply can be told to apply the patch only to the index or to
both the index and to the working tree.
- We cannot directly use has_symlink_leading_path() even when we
are applying only to the working tree, as an early patch of a
valid input may remove a symbolic link path/to/dir and then a
later patch of the input may create a path path/to/dir/file, but
git apply first checks the input without touching either the
index or the working tree. The leading symbolic link check must
be done on the interim result we compute in-core (i.e. after the
first patch, there is no path/to/dir symbolic link and it is
perfectly valid to create path/to/dir/file).
Similarly, when an input creates a symbolic link path/to/dir and
then creates a file path/to/dir/file, we need to flag it as an
error without actually creating path/to/dir symbolic link in the
filesystem.
Instead, for any patch in the input that leaves a path (i.e. a non
deletion) in the result, we check all leading paths against interim
result and then either the index or the working tree. The interim
results of applying patches are kept track of by fn_table logic for
us already, so use it to fiture out if existing a symbolic link will
cause problems, if a new symbolic link that will cause problems will
appear, etc.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* At least I convinced myself enough to say that I do not seem to
be breaking things with this patch, after taking patches out of
dozens of random pairs of commits from the Linux kernel history
and applying them using this version ;-) No code change since
last night's snapshot, but the test script is a bit more thorough
in this version.
builtin/apply.c | 44 +
t/t4122-apply-symlink-inside.sh | 62 +
2 files changed, 106 insertions(+)
diff --git a/builtin/apply.c b/builtin/apply.c
index ef32e4f..dcb44fb 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3483,6 +3483,46 @@ static int check_to_create(const char *new_name, int
ok_if_exists)
return 0;
}
+static int path_is_beyond_symlink(const char *name_)
+{
+ struct strbuf name = STRBUF_INIT;
+
+ strbuf_addstr(name, name_);
+ do {
+ struct patch *previous;
+
+ while (--name.len name.buf[name.len] != '/')
+ ; /* scan backwards */
+ if (!name.len)
+ break;
+ name.buf[name.len] = '\0';
+ previous = in_fn_table(name.buf);
+ if (previous) {
+ if (!was_deleted(previous)
+ !to_be_deleted(previous)
+ previous-new_mode
+ S_ISLNK(previous-new_mode))
+ goto symlink_found;
+ } else if (check_index) {
+ int pos = cache_name_pos(name.buf, name.len);
+ if (0 = pos
+ S_ISLNK(active_cache[pos]-ce_mode))
+ goto symlink_found;
+ } else {
+ struct stat st;
+ if (!lstat(name.buf, st) S_ISLNK(st.st_mode))
+ goto symlink_found;
+ }
+ } while (1);
+
+ strbuf_release(name);
+ return 0;
+symlink_found:
+ strbuf_release(name);
+ return 1;
+
+}
+
/*
* Check and apply the patch in-core; leave the result in patch-result
* for the caller to write it out to the final destination.
@@ -3570,6 +3610,10 @@ static int check_patch(struct patch *patch)
}
}
+ if (!patch-is_delete path_is_beyond_symlink(patch-new_name))
+ return error(_(affected file '%s' is beyond a symbolic link),
+patch-new_name);
+
if (apply_data(patch, st, ce) 0)
return error(_(%s: patch does not apply), name);
patch-rejected = 0;
diff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh
index 70b3a06..0a8de4a 100755
--- a/t/t4122-apply-symlink-inside.sh
+++ b/t/t4122-apply-symlink-inside.sh
@@ -52,4 +52,66 @@ test_expect_success 'check result' '
'
+test_expect_success SYMLINKS 'do not follow symbolic link (setup)' '
+
+ git reset --hard
+ ln -s ../i386/dir
Re* git loses commits on git pull --rebase with Dictator and Lieutenants Workflow
Dick d...@mrns.nl writes: I guess the git remote set-url --push command should contain some warning about this. Perhaps something like this would be good enough for a starter. -- 8 -- Subject: Documentation/git-remote.txt: stress that set-url is not for triangular It seems to be a common mistake to try using a single remote (e.g. 'origin') to fetch from one place (i.e. upstream) while pushing to another (i.e. your publishing point). That will never work satisfactory. Think about what refs/remotes/origin/* would mean in such a world---it fundamentally cannot reflect the reality. If it follows the state of your upstream, it cannot match what you have published, and vice versa. Some low-quality websites may be spreading misinformation. Let's counter them by adding a few words to our documentation. - The description was referring to oldurl and newurl, but never mentioned name argument you give from the command line. By mentioning remote name, stress the fact that it is configuring a single remote. - Add a reminder that explicitly states that this is about a single remote, which the triangular workflow is not about. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-remote.txt | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index cb103c8..a77607b 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -130,17 +130,25 @@ branches, adds to that list. 'set-url':: -Changes URL remote points to. Sets first URL remote points to matching +Changes URLs for the remote. Sets first URL for remote name that matches regex oldurl (first URL if no oldurl is given) to newurl. If -oldurl doesn't match any URL, error occurs and nothing is changed. +oldurl doesn't match any URL, an error occurs and nothing is changed. + With '--push', push URLs are manipulated instead of fetch URLs. + -With '--add', instead of changing some URL, new URL is added. +With '--add', instead of changing existing URLs, new URL is added. + -With '--delete', instead of changing some URL, all URLs matching -regex url are deleted. Trying to delete all non-push URLs is an -error. +With '--delete', instead of changing existing URLs, all URLs matching +regex url are deleted for remote name. Trying to delete all +non-push URLs is an error. ++ +Note that the push URL and the fetch URL, even though they can +be set differently, must still refer to the same place. What you +pushed to the push URL should be what you would see if you +immediately fetched from the fetch URL. If you are trying to +fetch from one place (e.g. your upstream) and push to another (e.g. +your publishing repository), use two separate remotes. + 'show':: -- 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: Re* git loses commits on git pull --rebase with Dictator and Lieutenants Workflow
On Thu, Jan 29, 2015 at 3:26 PM, Junio C Hamano gits...@pobox.com wrote: Subject: Documentation/git-remote.txt: stress that set-url is not for triangular It seems to be a common mistake to try using a single remote (e.g. 'origin') to fetch from one place (i.e. upstream) while pushing to another (i.e. your publishing point). That will never work satisfactory. Think about what refs/remotes/origin/* would s/satisfactory/satisfactorily/ mean in such a world---it fundamentally cannot reflect the reality. If it follows the state of your upstream, it cannot match what you have published, and vice versa. Some low-quality websites may be spreading misinformation. Let's counter them by adding a few words to our documentation. - The description was referring to oldurl and newurl, but never mentioned name argument you give from the command line. By mentioning remote name, stress the fact that it is configuring a single remote. - Add a reminder that explicitly states that this is about a single remote, which the triangular workflow is not about. Signed-off-by: Junio C Hamano gits...@pobox.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: [PATCH] apply: refuse touching a file beyond symlink
On Thu, Jan 29, 2015 at 12:45 PM, Junio C Hamano gits...@pobox.com wrote: + +test_expect_success SYMLINKS 'do not follow symbolic link (same input)' ' + + # same input creates a confusihng symbolic link s/confusihng/confusing/ -- 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/1] apply: reject input that touches outside $cwd
By default, a patch that affects outside the working area is
rejected as a mistake; Git itself never creates such a patch
unless the user bends backwards and specifies nonstandard
prefix to git diff and friends.
When `git apply` is used without either `--index` or `--cached`
option as a better GNU patch, the user can pass `--allow-uplevel`
option to override this safety check. This cannot be used to escape
outside the working tree when using `--index` or `--cached` to apply
the patch to the index.
The new test was stolen from Jeff King with slight enhancements.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* Meant to apply on top of the previous one, but these two are
about separate and orthogonal issues.
Documentation/git-apply.txt | 14 -
builtin/apply.c | 26 +
t/t4139-apply-escape.sh | 137
3 files changed, 176 insertions(+), 1 deletion(-)
create mode 100755 t/t4139-apply-escape.sh
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index f605327..20c3a6f 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -16,7 +16,7 @@ SYNOPSIS
[--ignore-space-change | --ignore-whitespace ]
[--whitespace=(nowarn|warn|fix|error|error-all)]
[--exclude=path] [--include=path] [--directory=root]
- [--verbose] [patch...]
+ [--verbose] [--allow-uplevel] [patch...]
DESCRIPTION
---
@@ -229,6 +229,18 @@ For example, a patch that talks about updating
`a/git-gui.sh` to `b/git-gui.sh`
can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
running `git apply --directory=modules/git-gui`.
+--allow-uplevel::
+ By default, a patch that affects outside the working area is
+ rejected as a mistake; Git itself never creates such a patch
+ unless the user bends backwards and specifies nonstandard
+ prefix to git diff and friends.
++
+When `git apply` is used without either `--index` or `--cached`
+option as a better GNU patch, the user can pass `--allow-uplevel`
+option to override this safety check. This cannot be used to escape
+outside the working tree when using `--index` or `--cached` to apply
+the patch to the index.
+
Configuration
-
diff --git a/builtin/apply.c b/builtin/apply.c
index dcb44fb..ce5a594 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -50,6 +50,7 @@ static int apply_verbosely;
static int allow_overlap;
static int no_add;
static int threeway;
+static int allow_uplevel;
static const char *fake_ancestor;
static int line_termination = '\n';
static unsigned int p_context = UINT_MAX;
@@ -3523,6 +3524,23 @@ symlink_found:
}
+static void die_on_uplevel_path(struct patch *patch)
+{
+ const char *old_name = NULL;
+ const char *new_name = NULL;
+ if (patch-is_delete)
+ old_name = patch-old_name;
+ else if (!patch-is_new !patch-is_copy)
+ old_name = patch-old_name;
+ if (!patch-is_delete)
+ new_name = patch-new_name;
+
+ if (old_name !verify_path(old_name))
+ die(_(invalid path '%s'), old_name);
+ if (new_name !verify_path(new_name))
+ die(_(invalid path '%s'), new_name);
+}
+
/*
* Check and apply the patch in-core; leave the result in patch-result
* for the caller to write it out to the final destination.
@@ -3614,6 +3632,9 @@ static int check_patch(struct patch *patch)
return error(_(affected file '%s' is beyond a symbolic link),
patch-new_name);
+ if (!allow_uplevel)
+ die_on_uplevel_path(patch);
+
if (apply_data(patch, st, ce) 0)
return error(_(%s: patch does not apply), name);
patch-rejected = 0;
@@ -4423,6 +,8 @@ int cmd_apply(int argc, const char **argv, const char
*prefix_)
N_(make sure the patch is applicable to the current
index)),
OPT_BOOL(0, cached, cached,
N_(apply a patch without touching the working tree)),
+ OPT_BOOL(0, allow-uplevel, allow_uplevel,
+ N_(accept a patch to touch outside the current
directory)),
OPT_BOOL(0, apply, force_apply,
N_(also apply the patch (use with
--stat/--summary/--check))),
OPT_BOOL('3', 3way, threeway,
@@ -4495,6 +4518,9 @@ int cmd_apply(int argc, const char **argv, const char
*prefix_)
die(_(--cached outside a repository));
check_index = 1;
}
+ if (check_index)
+ allow_uplevel = 0;
+
for (i = 0; i argc; i++) {
const char *arg = argv[i];
int fd;
diff --git a/t/t4139-apply-escape.sh b/t/t4139-apply-escape.sh
new file mode 100755
index 000..39de838
--- /dev/null
+++ b/t/t4139-apply-escape.sh
@@ -0,0 +1,137 @@
Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Valery Yundin yuval...@gmail.com wrote:
Hi,
Here you go:
dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit
Thank you. Can you give the following patch a try?
I have not been able to reproduce the problem on my end.
If it doesn't work out, I might be out of ideas for a bit :/
Increasing --log-window-size will help you run longer without
the error, but that's not ideal as it can also eat memory.
---8--
From: Eric Wong normalper...@yhbt.net
Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA
This may fix the errors some users are seeing with:
write .git/Git_svn_hash_XX: Bad file descriptor
Thanks to Valery Yundin for helping bisect the problem introduced in
commit dfa72fdb96befbd790f623bb2909a347176753c2
(git-svn: reload RA every log-window-size)
Cc: Valery Yundin yuval...@gmail.com
Signed-off-by: Eric Wong normalper...@yhbt.net
---
perl/Git.pm| 6 ++
perl/Git/SVN/Ra.pm | 1 +
2 files changed, 7 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index b5905ee..698018e 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1347,6 +1347,12 @@ sub temp_path {
$TEMP_FILES{$temp_fd}{fname};
}
+sub temp_reset_all {
+ unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
+ %TEMP_FILEMAP = ();
+ %TEMP_FILES = ();
+}
+
sub END {
unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
}
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 622535e..878679d 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
$_[0] = undef;
$self = undef;
$RA = undef;
+ Git-temp_reset_all;
$gpool-clear;
$self = Git::SVN::Ra-new($ra_url);
$ra_invalid = undef;
--
EW
--
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 svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Hi,
Your patch seems to fix the problem.
I tried several times and I can svn clone the whole repository in one
go without a crash.
Thanks,
Valery
On 30 January 2015 at 01:22, Eric Wong normalper...@yhbt.net wrote:
Valery Yundin yuval...@gmail.com wrote:
Hi,
Here you go:
dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit
Thank you. Can you give the following patch a try?
I have not been able to reproduce the problem on my end.
If it doesn't work out, I might be out of ideas for a bit :/
Increasing --log-window-size will help you run longer without
the error, but that's not ideal as it can also eat memory.
---8--
From: Eric Wong normalper...@yhbt.net
Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA
This may fix the errors some users are seeing with:
write .git/Git_svn_hash_XX: Bad file descriptor
Thanks to Valery Yundin for helping bisect the problem introduced in
commit dfa72fdb96befbd790f623bb2909a347176753c2
(git-svn: reload RA every log-window-size)
Cc: Valery Yundin yuval...@gmail.com
Signed-off-by: Eric Wong normalper...@yhbt.net
---
perl/Git.pm| 6 ++
perl/Git/SVN/Ra.pm | 1 +
2 files changed, 7 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index b5905ee..698018e 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1347,6 +1347,12 @@ sub temp_path {
$TEMP_FILES{$temp_fd}{fname};
}
+sub temp_reset_all {
+ unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
+ %TEMP_FILEMAP = ();
+ %TEMP_FILES = ();
+}
+
sub END {
unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
}
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 622535e..878679d 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
$_[0] = undef;
$self = undef;
$RA = undef;
+ Git-temp_reset_all;
$gpool-clear;
$self = Git::SVN::Ra-new($ra_url);
$ra_invalid = undef;
--
EW
--
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 svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Valery Yundin yuval...@gmail.com wrote: Tested on: git-svn version 2.3.0.rc2 (svn 1.8.11) - FAIL git-svn version 2.2.2 (svn 1.8.10) - FAIL git-svn version 1.8.4.5 (svn 1.8.11) - WORKS Thank you for that info. Do you think you can bisect which versions/revisions of git-svn introduced that failure for us? I don't have much time this part of the year for git-svn, but maybe it's related to the performance work we did around fall 2014. Thanks again. -- 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 svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Valery Yundin yuval...@gmail.com wrote:
Hi,
Your patch seems to fix the problem.
I tried several times and I can svn clone the whole repository in one
go without a crash.
Thanks for the confirmation. Cc-ing a few other folks who encountered
this problem (and Bcc-ing some folks who emailed me privately).
Can the rest of you give this patch a try on your respective platforms
and confirm the fix?
http://article.gmane.org/gmane.comp.version-control.git/263168/raw
(also: http://mid.gmane.org/20150130002247.ga22...@dcvr.yhbt.net )
Junio: assuming all goes well with testers, can you apply my patch
to the appropriate maintenance tracks with Tested-by:s?
I'm going offline in a few hours and don't think I'll be around
much the next week or so.
Thanks.
Thanks,
Valery
On 30 January 2015 at 01:22, Eric Wong normalper...@yhbt.net wrote:
Valery Yundin yuval...@gmail.com wrote:
Hi,
Here you go:
dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit
Thank you. Can you give the following patch a try?
I have not been able to reproduce the problem on my end.
If it doesn't work out, I might be out of ideas for a bit :/
Increasing --log-window-size will help you run longer without
the error, but that's not ideal as it can also eat memory.
---8--
From: Eric Wong normalper...@yhbt.net
Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA
This may fix the errors some users are seeing with:
write .git/Git_svn_hash_XX: Bad file descriptor
Thanks to Valery Yundin for helping bisect the problem introduced in
commit dfa72fdb96befbd790f623bb2909a347176753c2
(git-svn: reload RA every log-window-size)
Cc: Valery Yundin yuval...@gmail.com
Signed-off-by: Eric Wong normalper...@yhbt.net
---
perl/Git.pm| 6 ++
perl/Git/SVN/Ra.pm | 1 +
2 files changed, 7 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index b5905ee..698018e 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1347,6 +1347,12 @@ sub temp_path {
$TEMP_FILES{$temp_fd}{fname};
}
+sub temp_reset_all {
+ unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
+ %TEMP_FILEMAP = ();
+ %TEMP_FILES = ();
+}
+
sub END {
unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
}
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 622535e..878679d 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
$_[0] = undef;
$self = undef;
$RA = undef;
+ Git-temp_reset_all;
$gpool-clear;
$self = Git::SVN::Ra-new($ra_url);
$ra_invalid = undef;
--
EW
--
--
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] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
The '--no-xmailer' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-xmailer) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--noxmailer'. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
See also:
d2559f734bba7fe5257720356a92f3b7a5b0d37c
907a0b1e04ea31cb368e9422df93d8ebb0187914
84eeb687de7a6c7c42af3fb51b176e0f412a979e
3fee1fe87144360a1913eab86af9ad136c810076
Signed-off-by: Tom G. Christensen t...@statsbiblioteket.dk
---
t/t9001-send-email.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index af6a3e8..30df6ae 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1580,20 +1580,20 @@ do_xmailer_test () {
test_expect_success $PREREQ '--[no-]xmailer without any configuration' '
do_xmailer_test 1 --xmailer
- do_xmailer_test 0 --no-xmailer
+ do_xmailer_test 0 --noxmailer
'
test_expect_success $PREREQ '--[no-]xmailer with sendemail.xmailer=true' '
test_config sendemail.xmailer true
do_xmailer_test 1
- do_xmailer_test 0 --no-xmailer
+ do_xmailer_test 0 --noxmailer
do_xmailer_test 1 --xmailer
'
test_expect_success $PREREQ '--[no-]xmailer with sendemail.xmailer=false' '
test_config sendemail.xmailer false
do_xmailer_test 0
- do_xmailer_test 0 --no-xmailer
+ do_xmailer_test 0 --noxmailer
do_xmailer_test 1 --xmailer
'
--
2.2.1
--
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
