[PATCH 1/1] skip RFC1991 tests with gnupg 2.1.x
--- t/lib-gpg.sh | 6 ++ t/t7004-tag.sh | 14 +++--- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index cd2baef..05b07c6 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -22,6 +22,12 @@ else GNUPGHOME=$(pwd)/gpghome export GNUPGHOME test_set_prereq GPG + case $gpg_version in + 'gpg (GnuPG) 2.1.'*) + say Your version of gpg (2.1.x) is missing some legacy features + test_set_prereq GNUPG21 + ;; + esac ;; esac fi diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh index 796e9f7..1c40967 100755 --- a/t/t7004-tag.sh +++ b/t/t7004-tag.sh @@ -1081,7 +1081,7 @@ test_expect_success GPG \ get_tag_header rfc1991-signed-tag $commit commit $time expect echo RFC1991 signed tag expect echo '-BEGIN PGP MESSAGE-' expect -test_expect_success GPG \ +test_expect_success GPG,!GNUPG21 \ 'creating a signed tag with rfc1991' ' echo rfc1991 gpghome/gpg.conf git tag -s -m RFC1991 signed tag rfc1991-signed-tag $commit @@ -1095,7 +1095,7 @@ cp $1 actual EOF chmod +x fakeeditor -test_expect_success GPG \ +test_expect_success GPG,!GNUPG21 \ 'reediting a signed tag body omits signature' ' echo rfc1991 gpghome/gpg.conf echo RFC1991 signed tag expect @@ -1103,13 +1103,13 @@ test_expect_success GPG \ test_cmp expect actual ' -test_expect_success GPG \ +test_expect_success GPG,!GNUPG21 \ 'verifying rfc1991 signature' ' echo rfc1991 gpghome/gpg.conf git tag -v rfc1991-signed-tag ' -test_expect_success GPG \ +test_expect_success GPG,!GNUPG21 \ 'list tag with rfc1991 signature' ' echo rfc1991 gpghome/gpg.conf echo rfc1991-signed-tag RFC1991 signed tag expect @@ -1123,12 +1123,12 @@ test_expect_success GPG \ rm -f gpghome/gpg.conf -test_expect_success GPG \ +test_expect_success GPG,!GNUPG21 \ 'verifying rfc1991 signature without --rfc1991' ' git tag -v rfc1991-signed-tag ' -test_expect_success GPG \ +test_expect_success GPG,!GNUPG21 \ 'list tag with rfc1991 signature without --rfc1991' ' echo rfc1991-signed-tag RFC1991 signed tag expect git tag -l -n1 rfc1991-signed-tag actual @@ -1139,7 +1139,7 @@ test_expect_success GPG \ test_cmp expect actual ' -test_expect_success GPG \ +test_expect_success GPG,!GNUPG21 \ 'reediting a signed tag body omits signature' ' echo RFC1991 signed tag expect GIT_EDITOR=./fakeeditor git tag -f -s rfc1991-signed-tag $commit -- 2.1.3 -- 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] list-objects: mark fewer commits as edges for non-shallow clones
On Thu, Dec 11, 2014 at 10:46 AM, brian m. carlson sand...@crustytoothpaste.net wrote: In commit fbd4a70 (list-objects: mark more commits as edges in mark_edges_uninteresting - 2013-08-16), we made --thin much more aggressive by reading lots more trees. This produces much smaller packs for shallow clones; however, it causes a significant performance regression for non-shallow clones with lots of refs (23.322 seconds vs. 4.785 seconds with 22400 refs). Limit this extra edge-marking to shallow clones to avoid poor performance. I'm glad it's now working better for you. Out of curiosity, have you enabled pack bitmap on this repo? I would expect it to reduce time some (or a lot) more, or we would find something to optimize further. -- 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
[PATCH v2 1/1] create gpg homedir on the fly and skip RFC1991 tests for gnupg 2.1
GnuPG 2.1 homedir looks different, so just creat it on the fly by
importing needed private and public keys and ownertrust.
This solves an issue with gnupg 2.1 running interactive pinentry when
old secret key is present.
Additionally GnuPG 2.1 does not longer support RFC1991, so skip these
tests.
---
t/lib-gpg.sh | 13 ++---
t/lib-gpg/ownertrust | 4
t/lib-gpg/random_seed | Bin 600 - 0 bytes
t/lib-gpg/trustdb.gpg | Bin 1360 - 0 bytes
t/t7004-tag.sh| 14 +++---
5 files changed, 21 insertions(+), 10 deletions(-)
create mode 100644 t/lib-gpg/ownertrust
delete mode 100644 t/lib-gpg/random_seed
delete mode 100644 t/lib-gpg/trustdb.gpg
diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index cd2baef..17c45ad 100755
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -16,12 +16,19 @@ else
# Type DSA and Elgamal, size 2048 bits, no expiration date.
# Name and email: C O Mitter commit...@example.com
# No password given, to enable non-interactive operation.
- cp -R $TEST_DIRECTORY/lib-gpg ./gpghome
- chmod 0700 gpghome
- chmod 0600 gpghome/*
+ mkdir ./gpghome
+ chmod 0700 ./gpghome
GNUPGHOME=$(pwd)/gpghome
export GNUPGHOME
+ gpg --homedir ${GNUPGHOME} --import \
+ $TEST_DIRECTORY/lib-gpg/pubring.gpg \
+ $TEST_DIRECTORY/lib-gpg/secring.gpg
+ gpg --homedir ${GNUPGHOME} --import-ownertrust \
+ $TEST_DIRECTORY/lib-gpg/ownertrust
test_set_prereq GPG
+ if [ -e ${GNUPGHOME}/pubring.kbx ]; then
+ test_set_prereq GNUPG21
+ fi
;;
esac
fi
diff --git a/t/lib-gpg/ownertrust b/t/lib-gpg/ownertrust
new file mode 100644
index 000..b3e3c4f
--- /dev/null
+++ b/t/lib-gpg/ownertrust
@@ -0,0 +1,4 @@
+# List of assigned trustvalues, created Thu 11 Dec 2014 01:26:28 PM CET
+# (Use gpg --import-ownertrust to restore them)
+73D758744BE721698EC54E8713B6F51ECDDE430D:6:
+D4BE22311AD3131E5EDA29A461092E85B7227189:3:
diff --git a/t/lib-gpg/random_seed b/t/lib-gpg/random_seed
deleted file mode 100644
index
95d249f15fce980f0e8c1a8a18b085b3885708aa..
GIT binary patch
literal 0
HcmV?d1
literal 600
zcmV-e0;m1ccZd+xTST*Lrq1x^ggx^+ymwieO!6X=U~ZH@{avIgxdn#ai{)Ou@Qw
za}Z!boffEq^fn)n?c=IEnDpt59Lnc)aR*;8Z;kgh_NW;ka;7Mt@v#sG(!Y9SSXWv
zQxd3WlyBr#4ltW6uKOoa6(r3df1VX$cG4`Om6hD-ckaX+Hb_yI?{f`hJQYk!1cM-
zoGeY~(Z7aYn$W06djh?W|CMsW=k@jgf=P2D1UA1T%vz0oE|OlIacG0xioPtSU
zNd#}P%YpJr-H65~J^RdqA!YV9BEvh7Gw^CdXg+Hp?kj=KGW|+|g$4?`trWWGuy$9
zv-|;8Y4(NRHWPyJ{epd{4%FHQKk5j}?0FFDAJ;0kIItZ4yJS?DIG4~0!#x~;X`!P
zO%+va?@`?yQnhjrP@#yjY$YO_0yk|1ddhc8Vru7d%ytet)mFZIUbPB3bvhHQ41
zNmnYeFxUMu=m$K5s=5_FJSR#oU3Y#X{(q7HTp-VYJ)%JjihbZ@R#GeqmU{0C4Q
zc}hUG+ighB{7XSaNw_h;=YtqacQB(Cg$e)^NTDD-oMD+T`O#-^|-ibj!pxHg+(
zlC$%zE836|E*F*((=O{Nn@K$taZO}!$tGMgsw?!=n_#(%X9Ha|$b=H@VstWYe;
zPUQL$$#9HTcOLoyEd6*A4TOEe3}c}GiW*^P1Lt{nHYUEAB`Qx7*wizaEyM$?AjVN
mb-6m)4=6PVqdRh+D!{c#q1!T9b(}OW7hrrT@nJcBO(OGA4ll
diff --git a/t/lib-gpg/trustdb.gpg b/t/lib-gpg/trustdb.gpg
deleted file mode 100644
index
4879ae9a84650a93a4d15bd6560c5d1b89eb4c2f..
GIT binary patch
literal 0
HcmV?d1
literal 1360
zcmZQfFGy!*W@Ke#VqggLnYN69fq@Z-(E%eDx(E*bs5NcGvvcX4tvN?+A7410el
zpr*s;$I$y;_DG5-p^?`;Pjx3vc@clMq$FB`O@(4fkGH5;5W#Id_(K1CUIi|N
zsvi2g;@3gdA(S!jFkIQEWGHo6ST63C=8{BCz1HnYg`Lb06^aOjybMdTjEeXLLrOJU
RgG}yTes6vJW7bzp^8ko~DZ2mw
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 796e9f7..1c40967 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1081,7 +1081,7 @@ test_expect_success GPG \
get_tag_header rfc1991-signed-tag $commit commit $time expect
echo RFC1991 signed tag expect
echo '-BEGIN PGP MESSAGE-' expect
-test_expect_success GPG \
+test_expect_success GPG,!GNUPG21 \
'creating a signed tag with rfc1991' '
echo rfc1991 gpghome/gpg.conf
git tag -s -m RFC1991 signed tag rfc1991-signed-tag $commit
@@ -1095,7 +1095,7 @@ cp $1 actual
EOF
chmod +x fakeeditor
-test_expect_success GPG \
+test_expect_success GPG,!GNUPG21 \
'reediting a signed tag body omits signature' '
echo rfc1991 gpghome/gpg.conf
echo RFC1991 signed tag expect
@@ -1103,13 +1103,13 @@ test_expect_success GPG \
test_cmp expect actual
'
-test_expect_success GPG \
+test_expect_success GPG,!GNUPG21 \
'verifying rfc1991 signature' '
echo rfc1991 gpghome/gpg.conf
git tag -v rfc1991-signed-tag
'
-test_expect_success GPG \
+test_expect_success GPG,!GNUPG21 \
'list tag with rfc1991 signature' '
echo rfc1991 gpghome/gpg.conf
echo rfc1991-signed-tag RFC1991 signed tag expect
@@ -1123,12 +1123,12 @@ test_expect_success GPG \
rm -f gpghome/gpg.conf
-test_expect_success GPG \
+test_expect_success
Re: [PATCH] added git-config support for diff.relative setting
On Thu, Dec 11, 2014 at 2:28 PM, Kelson kel...@shysecurity.com wrote:
@@ -270,6 +270,14 @@ int git_diff_basic_config(const char *var, const char
*value, void *cb)
return 0;
}
+ if (!strcmp(var, diff.relative)) {
+ if (git_config_bool(var, value))
+ DIFF_OPT_SET(default_diff_options, RELATIVE_NAME);
+ else
+ DIFF_OPT_CLR(default_diff_options, RELATIVE_NAME);
+ return 0;
+ }
+
if (starts_with(var, submodule.))
return parse_submodule_config_option(var, value);
This affects more than just git-diff. git_diff_ui_config() may be a
better place.
--
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
git objects mode 755 vs 700
Greetings, I have setup a git server for my company, but one problem I found is like the following problem: [root@localhost objects]# pwd /home/git/repositories/testing.git/objects [root@localhost objects]# ls -l total 0 drwx-- 2 git git 59 Dec 11 03:04 0e drwx-- 2 git git 59 Dec 11 03:14 11 drwx-- 2 git git 59 Dec 11 03:12 1b drwxr-xr-x 2 git git 59 Dec 5 02:53 24 drwx-- 2 git git 59 Dec 11 03:01 39 drwx-- 2 git git 59 Dec 11 03:01 42 drwx-- 2 git git 59 Dec 11 03:01 47 drwxr-xr-x 2 git git 59 Dec 5 02:57 4c As you can see, on the git server, take a repo ’testing.git’ as example, under the ‘objects’ directory, some sub-directory has 755 mode, but most of them are 700. To work with reviewboard, I export ‘repositories’ directory to NFS as readonly mode, but I need sub-directories under ‘objects’ to be 755 mode. Why some of them are of 755 but some 700? How can I set all sub-directories under ‘objects’ to be of 755 mode? -- Evan Li -- 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/1] replace binary keyrings with armored keys
---
t/lib-gpg.sh | 3 +-
t/lib-gpg/keyring.gpg | 88 ++
t/lib-gpg/pubring.gpg | Bin 2359 - 0 bytes
t/lib-gpg/secring.gpg | Bin 3734 - 0 bytes
4 files changed, 89 insertions(+), 2 deletions(-)
create mode 100644 t/lib-gpg/keyring.gpg
delete mode 100644 t/lib-gpg/pubring.gpg
delete mode 100644 t/lib-gpg/secring.gpg
diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index 17c45ad..ba5c7f2 100755
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -21,8 +21,7 @@ else
GNUPGHOME=$(pwd)/gpghome
export GNUPGHOME
gpg --homedir ${GNUPGHOME} --import \
- $TEST_DIRECTORY/lib-gpg/pubring.gpg \
- $TEST_DIRECTORY/lib-gpg/secring.gpg
+ $TEST_DIRECTORY/lib-gpg/keyring.gpg
gpg --homedir ${GNUPGHOME} --import-ownertrust \
$TEST_DIRECTORY/lib-gpg/ownertrust
test_set_prereq GPG
diff --git a/t/lib-gpg/keyring.gpg b/t/lib-gpg/keyring.gpg
new file mode 100644
index 000..fb1f048
--- /dev/null
+++ b/t/lib-gpg/keyring.gpg
@@ -0,0 +1,88 @@
+-BEGIN PGP PRIVATE KEY BLOCK-
+Version: GnuPG v1
+
+lQG7BEZnyykRBACzCPjIpTYNL7Y2tQqlEGTTDlvZcWNLjF5f7ZzuyOqNOidLUgFD
+36qch1LZLSZkShdR3Gae+bsolyjxrlFuFP0eXRPMtqK20aLw7WZvPFpEV1ThMne+
+PRJjYrvghWw3L0VVIAIZ8GXwrVBuU99uEjHEI0ojYloOvFc2jVPgSaoBvwCg48Tj
+fol2foSoJa7XUu9yAL8szg8D/RUsTzNF+I9hSRHl7MYKFMYoKEY9BDgrgAujp7YY
+8qdGsiUb0Ggyzp2kRjZFt4lpcvKhGfHn5GEjmtk+fRbD5qPfMqKFW+T0NPfYlYmL
+JJ4fs4qZ8Lx7x6iG6X51u+YNwsQuIGjMCC3CeNi3F7or651kkNYASbaQ1NROkCIN
+NudyA/0aasvoZUoNJAc2cP5Ifs6WhXMWLfMR2p2XbfKwKNYneec60usnSComcKqh
+sJVk0Gytvr3FOYVhRkXnKAbx+0W2urFP8OFVBTEKO6Ts2VygWGgneQYoHnqzwlUE
+yjOjlr+lyf7u2s/KAxpKA6jnttEdRZAmzWkhuox1wwAUkr27/QAAn3TEzKR1pxxR
++R3dHuFpnnfatMIDC5O0IkMgTyBNaXR0ZXIgPGNvbW1pdHRlckBleGFtcGxlLmNv
+bT6IXgQTEQIAHgUCRmfLKQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRATtvUe
+zd5DDXQdAKC92f+wOrTkbmPEf+u+qA/Gv6BxQwCfQ128JXCi3MpMB8tI2Kmo15tY
+gnmdAj0ERmfLThAIAM65eT9T6+gg0fJn+Qxhs3FFDPjxK6AOBS3SieWWmXO6stZZ
+plvb7r2+sXYp8HMHntnOX3TRPolIx1dsdkv3W3w8yUzf9Lmo2XMPsZ3/isWdEbOI
+A0rO3B1xwbQO7vEoWHeB7uyYIF6YsIH0pMqxkImciwB1tnJPB9OxqPHlD/HyyHr2
+voj6nmEGaPQWj8/dkfyenXm6XmNZUZL/slk6tRhNwv4cW3QQLh39nbiz9rqvZMKF
+XX8wkY4FdQkJjCGwqzG+7yJcyHvem29/iq//jRLZgdiN8BwV3MCTJyDp8/Wb/d9y
+jZcUm1RdtwRiwfhfQ+zmpyspm7OxINfH65rf7f8ABA0IALRiMRs/eOD59jrYXmPS
+ZQUbiALlbJJtuP2c9N3WZ5OgrhDiAW+SDIN+hgDynJ9b7C2dE3xNaud4zaXAAF44
+J4J0bAo2ZtZoJajw+GXwaZfh4Z7nPNHwEcbFD4/uXPCj9jPkcLOJqGmUY1aXdygo
+t3Hn5U/zo8JxPQ83YbJQhkzAOZ/HGowLNqKgGkLLHn1X9qay0CxlfTQeEN5RZyl3
+b4qRzGgGALFvoheyZIUw1TbjRpbn3kqlJooEQY02VwXFXfLI/LwzglilH6sSckvs
+0WHKLZ+0L6b3CgJHN2RsZ7QxwCBi1aemsvr65FeEXp/AYxaG5duUbsugG8PgoJ06
+bsEAAVQNQO3cXWpuiJ/nNLLnWuPunBKJUlurkBdf2GD+m+muF0VpwDchhqqbTO4e
+FqOISQQYEQIACQUCRmfLTgIbDAAKCRATtvUezd5DDcHsAKDQcoAtDWJFupVRqleB
+Cezx4Q2khACcCs+/LtE8Lb9hC+2cvr3uH5p82AI=
+=aEiU
+-END PGP PRIVATE KEY BLOCK-
+-BEGIN PGP PRIVATE KEY BLOCK-
+Version: GnuPG v1
+
+lQOYBFFMlkcBCADJi/xnAF8yI34PHilSCbM7VtOFO17oFMkpu4cgN2QpPuM5MVjy
+cvrzKSguZFvPCDLzeAFJW1uPxL4SHaHSkisCrFhijH7OJWcOPNPSFCwu+inAoAsv
+Hm4ns6pfDZyRjVTHSY4rdMISqKFRozaXu8vHeBRzIhFnubBCepKZW07oKPnrnELV
+TVUSUVI+6el8JFmJIWxxLNLhfRRSPF0v4MDXPF//iCWiZDI+J1pLvQ5V/f7YtfsD
+GV0oPY66J72BFJG555eKBttnNY901LmI3ocn5P5iVnXDaqMElw7FKpnANXucgY3H
+4kLyNkI3s3J0CGbXI7b3MBWtjctuhWv1q2G5ABEBAAEAB/wLiuza/qEfv1Cfj7FQ
+ytAXpz1YoAcrcM/53TeRQhrbvIee5ZNGhLdCkyot81QeuJrSaXO0E9CxRynrjQQ7
+ibYqN7Hy0uu1kAbQQJjmVdQXTKnKJ7Wm7oM4hYhNsVCKNXc+1+5AfDYGg4nZob36
+qqgHtc+Ardl5VfUg7uF+eZrnSMynjZANgikKbPtE09DKVtVOtUE4xTD9ijkpgn65
+glsZDqb7J4QVgTeEiCDKJsQvin3SwrPBqBxBRULF2TIaMbOwe6dHiiaI85rsvAWS
+VGzonUB3IU1470P2SDIVczbXYUK/nDSGx6ZZ0wLu9ZcCyUPvxVEykuh2P4UWHla+
+nHLRBADMLavcfjsCI5CRUsdurYpgE8Y3bEbcDpvzAu5jT5D25p3YPDODOXD3AKTt
+PzVMARVtv8twkbgAyWaoDevJz8OtmoSwsWjdFo4YvsYw9jV7Yf3GwzD3Ya1ZnW32
+JWQr6cX8qcK0AukAD7UZkVyhU2KBvB02t8lKHLbScHXTYVqrywQA/LNUXwmHji+6
+osnSQAC8X9ggMOEs9dGo7Qlk4JgfGAH17CFI3S3ubsaVEdxz3YwzOkD8SNmEbLyW
+a7CZ/RnpdAZU0nB7kSfbfZl7ajhPbgKBMsaV2yvaDdJeor4m5eKdXffRk0SksxjL
+Z/4P1tTIuL8WzetGB/aDcWDFgseSAAsEALzmf579ptlSmDyGRAKQqub+mj4V3EUZ
+1GVGcfBY86w3BZVDsaRiCtcNjk/lcP4AZ1Vbb42RM6jk8nLsENRc7rf2xa7ZPf0T
+6n5F6W+vk7EG76RoFhKVtGZngGKiDGVavxk3FT/yf8lKrT3wYiT03SZDuZ0pWvku
+FiJGEyesAC8WRz60JEVyaXMgRGlzY29yZGlhIDxkaXNjb3JkQGV4YW1wbGUubmV0
+PokBOAQTAQIAIgUCUUyWRwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ
+YQkuhbcicYlYowf7B+f+FDcLVfw8XzGlKku1F6PI1yGCt7AMO2/JkmO4LlgHuIgF
+pqe5b/XjKl0IsRcbVLitqiIokc8u+7H8yYU67DDliq7t1gqBy+qThSHcgn6WMKTa
+qCqOE2jzHyqulIAzQsJQ+c5SRofEZAKT4Qa2Dy+nsqWDpIE78aJd0Vnkk9U6H2Vu
+ABvUeN/IMgvxPr525o+rBD7LU4J3CtOzfV+sO6+33da+Bm9UhkR4tC4H/n1dDN1J
+YuxBQbgxTq/h8mKe4/7/Yvy+5WsYd96ZRLE2ZFWeWXtKkwmYbQ42G3SZUXaZ8R8O
+tbTyUrjbFKipO4wvXwhyju1l9cxAsrca6xbSCJ0DmARRTJZHAQgAqTtPFcTXqM+U
+o7bOoo+dcHi8XDf/8XSEmZfMKc/U5pSTBk7h1gSKuGzjF2n3wQm6A8+101vTLaQ6
+PoFDFW8uQB00mjymGrRDYFgz8bjhnaekZnA4XThr1ROjffgMhs3uTpCebdV+lL8K
+0oJTHc39TPLTg23DFcRSDN+3ARJJS7+CRBIbt9L5gObpgA4HUap/o6N7O04rQOPU
Re: [PATCH] gitignore.txt: do not suggest assume-unchanged
Jonathan Nieder schrieb am 10.12.2014 um 02:06:
Michael J Gruber wrote:
git-update-index --assume-unchanged was never meant to ignore changes
to tracked files (only to spare some stats). So do not suggest it
as a means to achieve that.
[...]
+++ b/Documentation/gitignore.txt
@@ -138,9 +138,6 @@ NOTES
The purpose of gitignore files is to ensure that certain files
not tracked by Git remain untracked.
-To ignore uncommitted changes in a file that is already tracked,
-use 'git update-index {litdd}assume-unchanged'.
-
To stop tracking a file that is currently tracked, use
'git rm --cached'.
Makes sense.
But we need some advice to replace the paragraph you are deleting. Is
the idea something like
Git will not ignore uncommitted changes in a file that is already
tracked.
If you have time to work on that, please contact git@vger.kernel.org.
(perhaps without that second line)?
Thanks,
Jonathan
I seems you're missing that info only because you know what used to be
there.
If you reread - trying to read only what is there now - you will see
that the text clearly says: gitignore files are about ignoring untracked
files to ensure that they remain untracked.
But maybe I'm somewhat professionally preoccupied :)
That is: Even if it clearly says it is about untracked files, it doesn't
hurt to say what it is not about (namely tracked files). It's just that
it is not about many other things either.
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: [RFC/PATCH 2/5] glossary: introduce glossary lookup command
Junio C Hamano schrieb am 10.12.2014 um 23:50: Michael J Gruber g...@drmicha.warpmail.net writes: When using a localised git, there are many reasons why a correspondence between English and localised git terms is needed: - connect localised messages with English ones (porcelain vs. plumbing) - connect localised messages with English man pages or online docs - help out someone in a different locale Introduce a `git glossary' command that leverages the existing infrastructure in three possible ways: - `git glossary' lists all glossary terms along with their translation - `git glossary foo' matches `foo' in the glossary (both English and localisation; partial matches shown) - `git glossary -a foo' matches `foo' in the git message catalogue (English, exact match only). Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Some bike-shedding expected regarding the interface... Once I've learned how to test l10n stuff, this will be amended. This is interesting. I wondered if we want to also have the associated documentation in response to a query, but I am not sure how well that would go without having a translated glossary at least. I.e. pulling the Yes, I think we would need something different then. The glossary entries are asciidoc which we can't format easily from the glossary command. I really think of the glossary command as being orthogonal to the definitory glossary. I guess I should name it translate instead. It's just that I don't know how to do the translation from the locale back to English for stuff in the message catalogue (i.e. how to search the translations), unless I list the msgids the way I do for the glossary terms. It could be any list of terms. The glossary seemed to be a good place for that list of most important terms which users may want to translate both ways. original from glossary-content.txt would produce something like this: $ LANG=de git glossary -l blob object Blob-Objekten Untyped def_object,object, e.g. the contents of a file. which is not ideal. I noticed that you allow querying more than one term from the command line, so the above example would not work quite well, as we would end up querying blob and then object, not a single term blob object which does have N_() translation in glossary.h. Exactly, one would need to query for blob object. Or we concatenate arguments automatically, but I think being able to query multiple terms (also) is more useful. 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: [PATCH 1/1] skip RFC1991 tests with gnupg 2.1.x
On 11.12.14 10:30, Christian Hesse wrote: --- t/lib-gpg.sh | 6 ++ t/t7004-tag.sh | 14 +++--- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index cd2baef..05b07c6 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -22,6 +22,12 @@ else GNUPGHOME=$(pwd)/gpghome export GNUPGHOME test_set_prereq GPG + case $gpg_version in + 'gpg (GnuPG) 2.1.'*) + say Your version of gpg (2.1.x) is missing some legacy features + test_set_prereq GNUPG21 + ;; + esac ;; esac fi We do not really need the GNUPG21 (and we don't need to touch the TC at all) case $gpg_version in 'gpg (GnuPG) 2.1.'*) say Your version of gpg (2.1.x) is missing some legacy features ;; *) test_set_prereq GPG ;; esac ;; -- 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] t1400: add some more tests of update-ref --stdin's verify command
On 12/10/2014 6:47 PM, Michael Haggerty wrote: Two of the tests fail because verify refs/heads/foo with no argument (not even zeros) actually *deletes* refs/heads/foo. This problem will be fixed in the next commit. Reviewed-by: Brad King brad.k...@kitware.com -Brad -- 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] update-ref: fix verify command with missing oldvalue
On 12/10/2014 6:47 PM, Michael Haggerty wrote: set have_old unconditionally and set old_sha1 to null_sha1. Reviewed-by: Brad King brad.k...@kitware.com -Brad -- 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/1] skip RFC1991 tests with gnupg 2.1.x
Torsten Bögershausen schrieb am 11.12.2014 um 16:32: On 11.12.14 10:30, Christian Hesse wrote: --- t/lib-gpg.sh | 6 ++ t/t7004-tag.sh | 14 +++--- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index cd2baef..05b07c6 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -22,6 +22,12 @@ else GNUPGHOME=$(pwd)/gpghome export GNUPGHOME test_set_prereq GPG +case $gpg_version in +'gpg (GnuPG) 2.1.'*) +say Your version of gpg (2.1.x) is missing some legacy features +test_set_prereq GNUPG21 +;; +esac ;; esac fi We do not really need the GNUPG21 (and we don't need to touch the TC at all) case $gpg_version in 'gpg (GnuPG) 2.1.'*) say Your version of gpg (2.1.x) is missing some legacy features ;; *) test_set_prereq GPG ;; esac ;; That would disable all GPG tests, which is pretty harsh. If gpg 2.1 is the future of gpg (which I don't know), which should rather prepare for that and make our tests independent of the version. Is gpg 2.1 stable enough to cater for its special needs? 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
[PATCH] git-check-ignore.txt: Clarify exit codes
check-ignore disregards whether a path is matched by a positive or negative pattern. Thus for a file that is _not_ ignored, but is captured by negative pattern in .gitignore, the exit code is 0. The docs suggested otherwise. Clarify docs to explain that only the match matters, not whether the path is actually ignored or not. Signed-off-by: Florian Hassanen florian.hassa...@gmail.com --- Today when working with the check-ignore command, I misunderstood the docs into thinking, that I could use check-ignore's exit code to determine, whether a file is ignored or not - but this is not how the exit code works :( Here is a suggestion, on how to update the docs to describe the exit code's behavior more clearly. Documentation/git-check-ignore.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index ee2e091..bdd8b7c 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -97,10 +97,11 @@ EXIT STATUS --- 0:: - One or more of the provided paths is ignored. + At least one of the provided paths matches some (possibly negative) + pattern. 1:: - None of the provided paths are ignored. + None of the provided paths match any pattern. 128:: A fatal error was encountered. -- 2.1.3 -- 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] list-objects: mark fewer commits as edges for non-shallow clones
brian m. carlson sand...@crustytoothpaste.net writes:
In commit fbd4a70 (list-objects: mark more commits as edges in
mark_edges_uninteresting - 2013-08-16), we made --thin much more
aggressive by reading lots more trees. This produces much smaller packs
for shallow clones; however, it causes a significant performance
regression for non-shallow clones with lots of refs (23.322 seconds vs.
4.785 seconds with 22400 refs). Limit this extra edge-marking to
shallow clones to avoid poor performance.
This change affects non-clone/fetch uses of object listing depending
on the shallowness of the repository, and does not even care if it
is driven as part of the pack-object codepath, if I am reading it
correctly. It smells wrong.
The problematic fbd4a70 already had unintended fallout that needed
to be corrected with 200abe74 (list-objects: only look at cmdline
trees with edge_hint, 2014-01-20). The current code with the fix,
the decision to use the more expensive marking is tied to
edge_hint. I notice that edge_hint is turned on only if the caller
of rev-list passes the --objects-edge option, and currently that
only happens in the pack-objects codepath when thin is given.
Perhaps that part should decide if it really wants to do edge_hint
depending on the shallowness of the repository perhaps?
That is, something like this instead?
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 3f9f5c7..a9ebf56 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2709,7 +2709,7 @@ int cmd_pack_objects(int argc, const char **argv, const
char *prefix)
usage_with_options(pack_usage, pack_objects_options);
argv_array_push(rp, pack-objects);
- if (thin) {
+ if (thin is_repository_shallow()) {
use_internal_rev_list = 1;
argv_array_push(rp, --objects-edge);
} else
--
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] list-objects: mark fewer commits as edges for non-shallow clones
Junio C Hamano gits...@pobox.com writes:
This change affects non-clone/fetch uses of object listing depending
on the shallowness of the repository, and does not even care if it
is driven as part of the pack-object codepath, if I am reading it
correctly. It smells wrong.
The problematic fbd4a70 already had unintended fallout that needed
to be corrected with 200abe74 (list-objects: only look at cmdline
trees with edge_hint, 2014-01-20). The current code with the fix,
the decision to use the more expensive marking is tied to
edge_hint. I notice that edge_hint is turned on only if the caller
of rev-list passes the --objects-edge option, and currently that
only happens in the pack-objects codepath when thin is given.
Perhaps that part should decide if it really wants to do edge_hint
depending on the shallowness of the repository perhaps?
That is, something like this instead?
Eh, perhaps not like that, as that would disable milder use of
thin when fetching into non-shallow repository.
The right approach would be more like allocating one more bit in
struct rev_info (call that edge_hint_aggressive), give a new option
--objects-edge-aggressive, and do something like
if (thin) {
use_internal_rev_list = 1;
argv_array_push(rp, is_repository_shallow()
? --objects-edge-aggressive
: --objects-edge);
}
in this codepath? I'd actually suggest is_repository_shallow()
detection to happen one level even higher (i.e. make decision at the
caller of pack-objects) and decide to pass either --thin or
--thin-aggressive, so that we can make sure that the damage caused
by fbd4a70 to be limited only to fetches into shallow repository
with stronger confidence.
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 3f9f5c7..a9ebf56 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2709,7 +2709,7 @@ int cmd_pack_objects(int argc, const char **argv, const
char *prefix)
usage_with_options(pack_usage, pack_objects_options);
argv_array_push(rp, pack-objects);
- if (thin) {
+ if (thin is_repository_shallow()) {
use_internal_rev_list = 1;
argv_array_push(rp, --objects-edge);
} else
--
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 2/5] glossary: introduce glossary lookup command
Michael J Gruber g...@drmicha.warpmail.net writes: I wondered if we want to also have the associated documentation in response to a query, but I am not sure how well that would go without having a translated glossary at least. I.e. pulling the Yes, I think we would need something different then. The glossary entries are asciidoc which we can't format easily from the glossary command. I really think of the glossary command as being orthogonal to the definitory glossary. I guess I should name it translate instead. ... original from glossary-content.txt would produce something like this: $ LANG=de git glossary -l blob object Blob-Objekten Untyped def_object,object, e.g. the contents of a file. which is not ideal. I didn't mean the AsciiDoc part, though. I meant that the contents are not in LANG=de, which is not ideal. So translating blob object to whatever it is called in LANG=de, without the description, is the best we can do without having a translated documentation set. -- 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] commit: loosen ident checks when generating template
On Wed, Dec 10, 2014 at 10:42 AM, Jeff King p...@peff.net wrote: Signed-off-by: Jeff King p...@peff.net --- diff --git a/builtin/commit.c b/builtin/commit.c index d1c90db..2be5506 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -822,8 +821,14 @@ static int prepare_to_commit(const char *index_file, const char *prefix, status_printf_ln(s, GIT_COLOR_NORMAL, %s, only_include_assumed); - split_ident_or_die(ai, author_ident); - split_ident_or_die(ci, committer_ident); + /* +* These should never fail because we they come from our own s/we// +* fmt_ident. They may fail the sane_ident test, but we know +* that the name and mail pointers will at least be valid, +* which is enough for our tests and printing here. +*/ + assert_split_ident(ai, author_ident); + assert_split_ident(ci, committer_ident); if (ident_cmp(ai, ci)) status_printf_ln(s, GIT_COLOR_NORMAL, -- 2.2.0.454.g7eca6b7 -- 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 v3 23/23] untracked cache: guard and disable on system changes
On 10.12.14 13:22, Duy Nguyen wrote: On Wed, Dec 10, 2014 at 12:08 PM, Torsten Bögershausen tbo...@web.de wrote: That opens another question: How flexible/extensible/self-describing is the format of the UNTR extension ? If we drop the OS name root dir check because it disallows network use, but later add a better method to verify that the underlying chain local OS - network - remote OS-remote FS is OK, do we need to change the file format of UNTR ? If yes, can old clients read the new format and vice versa? Do we need a version information of some kind, or does the old client skip unknown entries like we do with extensions in the index ? The way index extensions are done so far, there's no actual versioning inside an extension.Once an extension is out, its format is set in stone. If you change your mind, you make a new extension (with a different signature), so signatures are sort of version. Code is shared mostly so it should not be a problem. Old clients don't recognize new extensions, so they drop them. New clients either stick to old extensions or convert them to new ones. This is all local matters, so I don't think we need to worry too much. Thanks for the info. Even if I share the the concerns that the cache may work on one system, but not on the other, there should be better ways to protect from that. Using the uname does not really help, if you move one repo from NTFS to VFAT, we will not detect it (assuming we use Windows). (And how much do we need to support the move of a repo ?) There is a concern that this may not work, when different clients are accessing the repo, using the UNTR extension. Some kind of sanity check would be good to have, what can be done ? The most important things are the timestamps. I can think of 2 sanity checks: - If the modified time stamp of a directory is older then the create time of any file, the UNTR cache can not be used. - If the timestamp of a file changes, but the sha1 sum is the same, what does this mean? The file (or the whole repo) has been copied, or the time stamping does not work. A simple verification of the FS could be to stat() .git/, create a temp file, delete it and stat() again. If mtime does not change, the FS is unusable for UNTR. Then we could extend the uname idea: Create a string in UNTR which is a collection of lines like this: Working-For: Linux;/mnt/nfs/projects/project1 Not-OK-For: WIndows:/a:/project1 (Of course the strings can be made nicer, and '\n' is URL-encoded.) Each system that is not listed needs to probe the repo, add another line and re-write the index. We can even add a best-for line, and invalidate the UNTR every 12 hours or so. Should we think about having an ASCII area for additional information, which is part of the stone, but the content is flexible ? The patch-series really speeds up git status on a network, thanks for working on it. The next days^H^H^H^H weeks I will do some more tests, using different combinations of OS and network protocols. -- 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] added git-config support for diff.relative setting
That is quite manageable. I was concerned that --relative changes the UI
(relative paths) and behavior (excluding files outside the current
directory), which might not be clear if placed in just the UI component.
You make a great point that git_diff_basic_config drives other commands
though, like git-bisect, which --relative would not effect.
-Original Message-
From: Duy Nguyen pclo...@gmail.com
Sent: 12/11/2014 08:37 AM
To: Kelson kel...@shysecurity.com
CC: Git Mailing List git@vger.kernel.org
Subject: Re: [PATCH] added git-config support for diff.relative setting
On Thu, Dec 11, 2014 at 2:28 PM, Kelson kel...@shysecurity.com wrote:
@@ -270,6 +270,14 @@ int git_diff_basic_config(const char *var, const char
*value, void *cb)
return 0;
}
+ if (!strcmp(var, diff.relative)) {
+ if (git_config_bool(var, value))
+ DIFF_OPT_SET(default_diff_options, RELATIVE_NAME);
+ else
+ DIFF_OPT_CLR(default_diff_options, RELATIVE_NAME);
+ return 0;
+ }
+
if (starts_with(var, submodule.))
return parse_submodule_config_option(var, value);
This affects more than just git-diff. git_diff_ui_config() may be a
better place.
--
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/8] refs.c: rename the transaction functions
Stefan Beller sbel...@google.com writes: Rename the transaction functions. Remove the leading ref_ from the names and append _ref to the names for functions that create/delete/ update sha1 refs. The goal in the long term is to have different things running through the transaction api, such as the .git/config file. The dream is to... I was trying to polish somebody else's topic that does not have anythning to do with refs/reflogs/transactions today, and had to suffer from conflicts from the textual difference between transaction_begin and ref_transaction_begin, which I feel is totally unnecessary at this moment. I'd really prefer to see this done long after all the dust from ref changes from various people have settled, especially given that we are not doing anything for that dream right now. 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/8] refs.c: rename the transaction functions
On Thu, Dec 11, 2014 at 1:42 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: Rename the transaction functions. Remove the leading ref_ from the names and append _ref to the names for functions that create/delete/ update sha1 refs. The goal in the long term is to have different things running through the transaction api, such as the .git/config file. The dream is to... I was trying to polish somebody else's topic that does not have anythning to do with refs/reflogs/transactions today, and had to suffer from conflicts from the textual difference between transaction_begin and ref_transaction_begin, which I feel is totally unnecessary at this moment. I'd really prefer to see this done long after all the dust from ref changes from various people have settled, especially given that we are not doing anything for that dream right now. Thanks. Good point. For the last days I was trying to write less invasive patches as I guessed this may become a problem. Feel free to drop these patches, I'll resend them later if they still make sense. -- 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 4/8] refs.c: add transaction function to append to the reflog
Stefan Beller sbel...@google.com writes: Unlike transaction_update_ref, this writes out the proposed contents of the reflog to a temporary file at transaction_reflog_update time instead of waiting for the transaction waiting to be committed. This avoids an explosion of memory usage when writing lots of reflog updates within a single transaction. Copying an existing reflog with thousands of entries over so that I can append a single new entry, just so that I can rollback by not renaming? After ensuring that you are the only process that holds a write fd to the reflog file (e.g. by taking a lock on the ref itself), shouldn't you be able to ftell(), write() and then truncate() to roll back sanely before close()? After all you are not protecting from power loss and other kinds of glitches that would leave *.lock file behind, so... -- 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: no-xmailer tests fail under Mac OS
Jeff King p...@peff.net writes:
On Fri, Dec 05, 2014 at 11:07:37PM -0800, Michael Blume wrote:
Ah, right, we might be looking for 0 sometimes. The right way to do it
without destroying the -chaining is:
{ grep ^X-Mailer: out || true }
test_line_count = $expected mailer
Hmm, it doesn't look like that helper is -chained though? So it
seems like we could just do without the
You're right, but that is IMHO a bug. We would not notice if send-email
or format-patch barfed, and we are expecting to find no X-Mailer (we
wouldn't, but for the wrong reason).
Let me patch this up further by amending the SQUASH??? at the tip.
t/t9001-send-email.sh | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index bb573ef..7826aa8 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1408,18 +1408,17 @@ test_expect_success $PREREQ
'sendemail.aliasfile=~/.mailrc' '
'
do_xmailer_test() {
- expected=$1
- params=$2
- git format-patch -1
+ expected=$1 params=$2
+ git format-patch -1
git send-email \
--from=Example nob...@example.com \
--to=some...@example.com \
--smtp-server=$(pwd)/fake.sendmail \
$params \
0001-*.patch \
- 2errors out
- test z$(grep ^X-Mailer: out | wc -l) = z$expected
- return $?
+ 2errors out
+ { grep '^X-Mailer:' out || :; } mailer
+ test_line_count = $expected mailer
}
test_expect_success $PREREQ '--[no-]xmailer without any configuration' '
--
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: no-xmailer tests fail under Mac OS
On Thu, Dec 11, 2014 at 02:11:04PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Dec 05, 2014 at 11:07:37PM -0800, Michael Blume wrote:
Ah, right, we might be looking for 0 sometimes. The right way to do it
without destroying the -chaining is:
{ grep ^X-Mailer: out || true }
test_line_count = $expected mailer
Hmm, it doesn't look like that helper is -chained though? So it
seems like we could just do without the
You're right, but that is IMHO a bug. We would not notice if send-email
or format-patch barfed, and we are expecting to find no X-Mailer (we
wouldn't, but for the wrong reason).
Let me patch this up further by amending the SQUASH??? at the tip.
t/t9001-send-email.sh | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
[...]
Yeah, looks good to me.
-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: no-xmailer tests fail under Mac OS
Jeff King p...@peff.net writes:
On Thu, Dec 11, 2014 at 02:11:04PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Dec 05, 2014 at 11:07:37PM -0800, Michael Blume wrote:
Ah, right, we might be looking for 0 sometimes. The right way to do it
without destroying the -chaining is:
{ grep ^X-Mailer: out || true }
test_line_count = $expected mailer
Hmm, it doesn't look like that helper is -chained though? So it
seems like we could just do without the
You're right, but that is IMHO a bug. We would not notice if send-email
or format-patch barfed, and we are expecting to find no X-Mailer (we
wouldn't, but for the wrong reason).
Let me patch this up further by amending the SQUASH??? at the tip.
t/t9001-send-email.sh | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
[...]
Yeah, looks good to me.
-Peff
Same here. Thanks a lot for fixing this.
Cheers,
--
Luís
--
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 1/1] create gpg homedir on the fly and skip RFC1991 tests for gnupg 2.1
Christian Hesse m...@eworm.de writes:
GnuPG 2.1 homedir looks different, so just creat it on the fly by
importing needed private and public keys and ownertrust.
This solves an issue with gnupg 2.1 running interactive pinentry when
old secret key is present.
Additionally GnuPG 2.1 does not longer support RFC1991, so skip these
tests.
---
Needs a sign-off.
Are older GPG implementations still happy with this new way to
initialize their gpghome?
t/lib-gpg.sh | 13 ++---
t/lib-gpg/ownertrust | 4
t/lib-gpg/random_seed | Bin 600 - 0 bytes
t/lib-gpg/trustdb.gpg | Bin 1360 - 0 bytes
t/t7004-tag.sh| 14 +++---
5 files changed, 21 insertions(+), 10 deletions(-)
create mode 100644 t/lib-gpg/ownertrust
delete mode 100644 t/lib-gpg/random_seed
delete mode 100644 t/lib-gpg/trustdb.gpg
Do these trust files need to be shipped? In other words, would it
be insufficient to just import private-public keyrings? I know we
have been shipping trustdb.gpg, and I do not think it is a problem
to ship export-ownertrust output, but as long as we are cleaning
things up to make us compatible with both older and newer GPG,
I thought I'd ask ;-)
diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index cd2baef..17c45ad 100755
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -16,12 +16,19 @@ else
# Type DSA and Elgamal, size 2048 bits, no expiration date.
# Name and email: C O Mitter commit...@example.com
# No password given, to enable non-interactive operation.
- cp -R $TEST_DIRECTORY/lib-gpg ./gpghome
- chmod 0700 gpghome
- chmod 0600 gpghome/*
+ mkdir ./gpghome
+ chmod 0700 ./gpghome
GNUPGHOME=$(pwd)/gpghome
export GNUPGHOME
+ gpg --homedir ${GNUPGHOME} --import \
+ $TEST_DIRECTORY/lib-gpg/pubring.gpg \
+ $TEST_DIRECTORY/lib-gpg/secring.gpg
+ gpg --homedir ${GNUPGHOME} --import-ownertrust \
+ $TEST_DIRECTORY/lib-gpg/ownertrust
test_set_prereq GPG
+ if [ -e ${GNUPGHOME}/pubring.kbx ]; then
+ test_set_prereq GNUPG21
+ fi
Instead of !GNUPG21 prerequisite, how about using a RFC1991
prerequisite, which is satisfied by older GPG but not by the ones
that lack support? That is,
...
test_set_prereq GPG
if ! test ${GNUPGHOME}/pubring.kbx
then
test_set_prereq GPG_RFC1991
fi
or something. That way, we do not have to be in a funny situation
where we say a version of GPG satisfies GNUPG21 prereq but it in
fact is GPG version 4.3 in the future.
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: git objects mode 755 vs 700
Evan Li li.evan.c...@gmail.com writes: Why some of them are of 755 but some 700? How can I set all sub-directories under ‘objects’ to be of 755 mode? Some people who are pushing into the repository have 077 and some others have 022 as their umask, perhaps? If that is the case, perhaps core.sharedRepository configuration setting is what you want to use. -- 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/1] skip RFC1991 tests with gnupg 2.1.x
Michael J Gruber g...@drmicha.warpmail.net on Thu, 2014/12/11 17:54: Torsten Bögershausen schrieb am 11.12.2014 um 16:32: On 11.12.14 10:30, Christian Hesse wrote: --- t/lib-gpg.sh | 6 ++ t/t7004-tag.sh | 14 +++--- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index cd2baef..05b07c6 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -22,6 +22,12 @@ else GNUPGHOME=$(pwd)/gpghome export GNUPGHOME test_set_prereq GPG + case $gpg_version in + 'gpg (GnuPG) 2.1.'*) + say Your version of gpg (2.1.x) is missing some legacy features + test_set_prereq GNUPG21 + ;; + esac ;; esac fi We do not really need the GNUPG21 (and we don't need to touch the TC at all) case $gpg_version in 'gpg (GnuPG) 2.1.'*) say Your version of gpg (2.1.x) is missing some legacy features ;; *) test_set_prereq GPG ;; esac ;; That would disable all GPG tests, which is pretty harsh. Agreed. ;) It's just six tests we have to disable. Everything else works just perfectly. If gpg 2.1 is the future of gpg (which I don't know), which should rather prepare for that and make our tests independent of the version. Is gpg 2.1 stable enough to cater for its special needs? GnuPG 2.0.x is still the official stable, 2.1.x is the modern branch. Looks like the decision about whether or not 2.1.x will be stable has not been made yet. Though official stable is to be read as absolutely rock solid stable IMHO. That is what enterprise distributions should use. The modern branch is stable for daily use but has some experimental features. Arch Linux for example already uses it [0], so stability can not be that bad. ;) However... Even if GnuPG 2.2.x (or whatever future release) will become next stable: It will not reintroduce support for rfc1991. So applying my patch is the way to go. (And version 2 of the patch even simplifies things and makes it more generic.) [0] https://www.archlinux.org/packages/?name=gnupg -- Best Regards, Chris pgpWIt29SZXcQ.pgp Description: OpenPGP digital signature
Re: [PATCH] git-check-ignore.txt: Clarify exit codes
Florian Hassanen florian.hassa...@gmail.com writes: check-ignore disregards whether a path is matched by a positive or negative pattern. Thus for a file that is _not_ ignored, but is captured by negative pattern in .gitignore, the exit code is 0. The docs suggested otherwise. I am not sure that is the actual behaviour of the command. Given this .gitignore file: $ cat .gitignore; echo END !vendor.o *.o END which is designed to allow binary-only blob vendor.o supplied by the vendor to be tracked, but to ignore all the other usual build artifacts, you see this: $ for o in a.o vendor.o; do git check-ignore $o /dev/null; echo $?; done 0 1 Puzzled... Clarify docs to explain that only the match matters, not whether the path is actually ignored or not. Signed-off-by: Florian Hassanen florian.hassa...@gmail.com --- Today when working with the check-ignore command, I misunderstood the docs into thinking, that I could use check-ignore's exit code to determine, whether a file is ignored or not - but this is not how the exit code works :( Here is a suggestion, on how to update the docs to describe the exit code's behavior more clearly. Documentation/git-check-ignore.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index ee2e091..bdd8b7c 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -97,10 +97,11 @@ EXIT STATUS --- 0:: - One or more of the provided paths is ignored. + At least one of the provided paths matches some (possibly negative) + pattern. 1:: - None of the provided paths are ignored. + None of the provided paths match any pattern. 128:: A fatal error was encountered. -- 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/1] skip RFC1991 tests with gnupg 2.1.x
Christian Hesse m...@eworm.de writes: However... Even if GnuPG 2.2.x (or whatever future release) will become next stable: It will not reintroduce support for rfc1991. How certain are we about the deprecation? It also would make us feel safer if we did not have to depend on the version or keyfile format (which would not have anything to do with the decision to support or not to support rfc1991 format) to check if the feature is supported, but that is a separate issue. -- 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-check-ignore.txt: Clarify exit codes
check-ignore disregards whether a path is matched by a positive or negative pattern. Thus for a file that is _not_ ignored, but is captured by negative pattern in .gitignore, the exit code is 0. The docs suggested otherwise. I am not sure that is the actual behaviour of the command. Given this .gitignore file: $ cat .gitignore; echo END !vendor.o *.o END which is designed to allow binary-only blob vendor.o supplied by the vendor to be tracked, but to ignore all the other usual build artifacts, you see this: $ for o in a.o vendor.o; do git check-ignore $o /dev/null; echo $?; done 0 1 Puzzled... Maybe your global ignore file gets in the way? on both of my machines (cygwin + git 2.1.1, linux + git @master) I have: $ cat .gitignore EOF !vendor.o *.o EOF for o in a.o vendor.o; do git check-ignore $o /dev/null; echo $?; done 0 0 which corresponds to how I understand the command so far :) is one of a.o and vendor.o already in your index? there is a --no-index as well (which enables yet another different behavior) -- 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-check-ignore.txt: Clarify exit codes
Florian Hassanen florian.hassa...@gmail.com writes: Maybe your global ignore file gets in the way? No, as I do not have one. is one of a.o and vendor.o already in your index? Bingo. I did git add . to see if the .gitignore file is doing the right thing before running that demonstration. It smells like you spotted a bug in the behaviour, not a bug in the documentation, at least to me. -- 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] commit: ignore assume-unchanged files in commmit file mode
From: Sérgio Basto ser...@serjux.com Sent: Tuesday, December 09, 2014 2:44 AM On Sex, 2014-12-05 at 17:56 +0700, Nguyễn Thái Ngọc Duy wrote: In the same spirit of 7fce6e3 (commit: correctly respect skip-worktree bit - 2009-12-14), if a file is marked unchanged, skip it. Noticed-by: Sérgio Basto ser...@serjux.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- builtin/commit.c | 2 +- t/t2106-update-index-assume-unchanged.sh | 10 ++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index e108c53..ee3de12 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -252,7 +252,7 @@ static int list_paths(struct string_list *list, const char *with_tree, if (!ce_path_match(ce, pattern, m)) continue; item = string_list_insert(list, ce-name); - if (ce_skip_worktree(ce)) + if (ce-ce_flags (CE_VALID | CE_SKIP_WORKTREE)) item-util = item; /* better a valid pointer than a fake one */ } diff --git a/t/t2106-update-index-assume-unchanged.sh b/t/t2106-update-index-assume-unchanged.sh index 99d858c..dc332f5 100755 --- a/t/t2106-update-index-assume-unchanged.sh +++ b/t/t2106-update-index-assume-unchanged.sh @@ -21,4 +21,14 @@ test_expect_success 'do not switch branches with dirty file' \ git update-index --assume-unchanged file test_must_fail git checkout master' +test_expect_success 'commit paths ignore assume-unchanged files' ' + : anotherfile + git add anotherfile + echo dirty anotherfile + git commit -m one -- file anotherfile + git diff --name-only HEAD^ HEAD actual + echo anotherfile expected + test_cmp expected actual +' + test_done works great many thanks, Junio: Given that this patch avoids the user surprise that the `commit .` and `commit -a` produced unexpectedly different effects, should it also be included in the --assume unchanged patches? Or is the test inappropriate? I'm guessing that there will still be other potential 'gotcha' code paths that would still produce surprise though. 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] git-check-ignore.txt: Clarify exit codes
It smells like you spotted a bug in the behaviour, not a bug in the documentation, at least to me. At first I thought so as well :-) I even prepared a patch, just to find out, that existing tests specifically test for this unintuitive behavior. Then I read the docs in more detail and found this: If the pattern contained a ! prefix or / suffix, it will be preserved in the output. So it seems there is indeed the intent to output patterns, even if they are negated/negative. Another problem I see with providing correct behavior is this: If I do a test for a non existant file, it cannot be decided whether I mean a file or a directory. e.g. having a gitignore with a single line dir/ which only ignores die _directory_ dir, but not the _file_ dir the exit code for $ git check-ignore dir could either be 0 or 1, depending on whether a _file_ named dir or a _directory_ named dir was meant. I assume that the command is meant to get the applying entry of the gitignore and then its up to the consumer to provide additional logic to determine whether the path is actually ignored or not. I am not sure what the correct behavior should be. And whether some code already depends on this command. My personal preference, would be a behavior like $ # regardless whether dir exists or not $ git check-ignore dir # a file is meant $ git check-ignore dir/ # a directory is mean and the exit code should only depend on whether the file is actually ignored or not - and not if there is an arbitrary matching pattern in gitignore PS: btw, the previously discussed gitignore file should have read (note the order) cat .gitignore EOF *.o !vendor.o EOF because always the last matching entry applies (so exceptions must come last) - but the exit codes are still the same On Fri, Dec 12, 2014 at 12:21 AM, Junio C Hamano gits...@pobox.com wrote: Florian Hassanen florian.hassa...@gmail.com writes: Maybe your global ignore file gets in the way? No, as I do not have one. is one of a.o and vendor.o already in your index? Bingo. I did git add . to see if the .gitignore file is doing the right thing before running that demonstration. It smells like you spotted a bug in the behaviour, not a bug in the documentation, at least to me. -- 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] doc: core.ignoreStat clarify the --assume-unchanged effect
The assume-unchanged bit can be misunderstood. Be assertive about the expectation that file changes should update that flag. Signed-off-by: Philip Oakley philipoak...@iee.org --- Documentation/config.txt | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c26a7c8..81570b7 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -354,10 +354,11 @@ proxy use, while defaulting to a common proxy for external domains. core.ignoreStat:: If true, commands which modify both the working tree and the index will mark the updated paths with the assume unchanged bit in the - index. These marked files are then assumed to stay unchanged in the - working tree, until you mark them otherwise manually - Git will not - detect the file changes by lstat() calls. This is useful on systems - where those are very slow, such as Microsoft Windows. + index. These marked files are then expected to stay unchanged in the + working tree. If you change them you should mark their update manually. + Git will normally not detect the file changes by lstat() calls. + This is useful on systems where those calls are very slow, such as + cifs/Microsoft Windows. See linkgit:git-update-index[1]. False by default. -- 1.9.4.msysgit.0 -- 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] core.ignoreStat is affected by --assume-unchanged misunderstandings
A recent thread on the Msysgit mailing list https://groups.google.com/forum/#!topic/msysgit/d9CltDxx11g noted the config core.ignoreStat flag as a solution to slow performance on Windows 8.1 for their system. This config flag uses the --assume-unchanged flag to speed up systems with slow lstat(2) calls. Just like the regular --assume-changed documentation, this need some tweaking to be clear that it is not a poor man's .gitignore. Philip Oakley (1): doc: core.ignoreStat clarify the --assume-unchanged effect Documentation/config.txt | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) -- 1.9.4.msysgit.0 -- 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
