Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
On 28/06/13 22:42, Fredrik Gustafsson wrote: Hi, On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote: This allows the user some finer grained control over how the update is done. The primary motivation for this was interoperability with stgit however being able to intercept the submodule update process may prove useful for integrating or extending other tools. Signed-off-by: Chris Packham judge.pack...@gmail.com -- Hi, At $dayjob we have a number of users that are accustomed to using stgit. Stgit doesn't play nicely with git rebase which would be the logical setting for submodule.*.update for our usage. Instead we need to run 'stg rebase --merged' on those submodules that have been initialised with stgit. Our current solution is an in-house script which is a poor substitute for git submodule update. I'd much rather replace our script with git submodule update but we do have a requirement to keep stgit for the foreseeable future. Rather than narrowing in on stgit it seems logical to allow an arbitrary update command to be executed. --- Documentation/git-submodule.txt | 8 +++- git-submodule.sh| 22 +- 2 files changed, 28 insertions(+), 2 deletions(-) technically it looks fine to me (except for the lack of tests) but I'm not sure I follow the use case. In your case, you want to run a script to determinate if that certain submodule should use merge or rebase depending on whatever. And this can't be done with git submodule foreach because you want to know the sha1 to update to. Have I understood you correctly? Correct. We tend to have submodules that are just normal detached heads which we don't usually touch and others that are actively developed where we would use submodule.x.update=rebase (I personally do) but some developers want to use stgit on those repositories. Another approach could be to do a 'git pull --no-recurse-submodule' then use 'git submodule foreach script-that-does-the-rebase'. The benefit of the patch I sent is that it can be setup using the config variables[1] and updated the normal way along with the detached HEADs and those using plain git branches. There may be other use-cases for integration with other tools as well (e.g. something that updates a review tool when commits get rebased). -- [1] I'm not crazy about the name of submodule.*.update.command but I couldn't think of a better one. -- 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 v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement
GIT_ROOT_DIR=../../..
GIT_EXEC_PATH=$(cd $(dirname $0) cd ${GIT_ROOT_DIR} pwd)
GIT_MEDIAWIKI=$GIT_EXEC_PATH/contrib/mw-to-git
PATH=$GIT_MEDIAWIKI/contrib/mw-to-git:$PATH
GPLEXTRA=$GIT_MEDIAWIKI/contrib/mw-to-git
exec ${GIT_EXEC_PATH}/bin-wrappers/git $@
Should I do that in a reroll ?
Two possible alternatives:
- Is there a reason you would not want to install whatever Perl
modules you want to use via GITPERLLIB mechanism to
../../perl/blib/lib?
If we are making modifications to Git/Mediawiki.pm or even git-mw.perl
/ git-remote-mediawiki.perl, installing them without proper testing
beforehand seems wrong.
That's not installing (i.e. not make install), just a copy within
the source tree. Same as what's done in Git's toplevel.
Oh right, sorry, read it too quickly :/ Well, I still find it weird to
copy untested files out of contrib/mw-to-git/ though.
Another idea crossed my mind: for now the test suite creates a symlink
of git-remote-mediawiki in the toplevel if it's not installed. It
would be better to use the bin-wrapper in the testsuite I think ?
(plus, with the current solution, it may have problems finding the
latest Git::Mediawiki.pm)
--
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] perf-lib: fix start/stop of perf tests
ae75342 test-lib: rearrange start/end of test_expect_* and test_skip
changed the way tests are started/stopped, but did not update the perf
tests. They were therefore giving the wrong output, because of the
wrong test count. Fix this by starting and stopping the tests
correctly.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
t/perf/perf-lib.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index a816fbc..c61d535 100644
--- a/t/perf/perf-lib.sh
+++ b/t/perf/perf-lib.sh
@@ -150,6 +150,7 @@ exit $ret' 3 24
test_perf () {
+ test_start_
test $# = 3 { test_prereq=$1; shift; } || test_prereq=
test $# = 2 ||
error bug in the test script: not 2 or 3 parameters to
test-expect-success
@@ -187,7 +188,7 @@ test_perf () {
base=$perf_results_dir/$perf_results_prefix$(basename $0
.sh).$test_count
$TEST_DIRECTORY/perf/min_time.perl test_time.* $base.times
fi
- echo 3
+ test_finish_
}
# We extend test_done to print timings at the end (./run disables this
--
1.8.3.453.g1dfc63d
--
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] perf-lib: fix start/stop of perf tests
Thomas Gummerer t.gumme...@gmail.com writes:
ae75342 test-lib: rearrange start/end of test_expect_* and test_skip
changed the way tests are started/stopped, but did not update the perf
tests. They were therefore giving the wrong output, because of the
wrong test count. Fix this by starting and stopping the tests
correctly.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
Doh! Thanks for catching this.
t/perf/perf-lib.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh
index a816fbc..c61d535 100644
--- a/t/perf/perf-lib.sh
+++ b/t/perf/perf-lib.sh
@@ -150,6 +150,7 @@ exit $ret' 3 24
test_perf () {
+ test_start_
test $# = 3 { test_prereq=$1; shift; } || test_prereq=
test $# = 2 ||
error bug in the test script: not 2 or 3 parameters to
test-expect-success
@@ -187,7 +188,7 @@ test_perf () {
base=$perf_results_dir/$perf_results_prefix$(basename $0
.sh).$test_count
$TEST_DIRECTORY/perf/min_time.perl test_time.* $base.times
fi
- echo 3
+ test_finish_
}
# We extend test_done to print timings at the end (./run disables this
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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:YOUR EMAIL
I will like to discuss a very important oil project with you. I wrote to know if this is your valid email.Please, email me for details on: hyuklee5...@gmail.com Lee. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] commit: improve UTF-8 validation
This series contains a pair of patches that improve the validation of the UTF-8 used in commit messages. Invalid codepoints, such as surrogates and guaranteed non-characters, are rejected, along with overlong UTF-8 sequences. brian m. carlson (2): commit: reject invalid UTF-8 codepoints commit: reject overlong UTF-8 sequences commit.c | 28 +--- t/t3900-i18n-commit.sh | 17 + t/t3900/UTF-8-invalid.txt | 3 +++ t/t3900/UTF-8-overlong.txt | 3 +++ 4 files changed, 48 insertions(+), 3 deletions(-) create mode 100644 t/t3900/UTF-8-invalid.txt create mode 100644 t/t3900/UTF-8-overlong.txt -- 1.8.3.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
[PATCH 1/2] commit: reject invalid UTF-8 codepoints
The commit code already contains code for validating UTF-8, but it does not
check for invalid values, such as guaranteed non-characters and surrogates. Fix
this by explicitly checking for and rejecting such characters.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
commit.c | 18 +++---
t/t3900-i18n-commit.sh| 9 +
t/t3900/UTF-8-invalid.txt | 3 +++
3 files changed, 27 insertions(+), 3 deletions(-)
create mode 100644 t/t3900/UTF-8-invalid.txt
diff --git a/commit.c b/commit.c
index 888e02a..2280413 100644
--- a/commit.c
+++ b/commit.c
@@ -1244,6 +1244,7 @@ static int find_invalid_utf8(const char *buf, int len)
while (len) {
unsigned char c = *buf++;
int bytes, bad_offset;
+ unsigned int codepoint;
len--;
offset++;
@@ -1264,24 +1265,35 @@ static int find_invalid_utf8(const char *buf, int len)
bytes++;
}
- /* Must be between 1 and 5 more bytes */
- if (bytes 1 || bytes 5)
+ /* Must be between 1 and 3 more bytes */
+ if (bytes 1 || bytes 3)
return bad_offset;
/* Do we *have* that many bytes? */
if (len bytes)
return bad_offset;
+ /* Place the encoded bits at the bottom of the value. */
+ codepoint = (c 0x7f) bytes;
+
offset += bytes;
len -= bytes;
/* And verify that they are good continuation bytes */
do {
+ codepoint = 6;
+ codepoint |= *buf 0x3f;
if ((*buf++ 0xc0) != 0x80)
return bad_offset;
} while (--bytes);
- /* We could/should check the value and length here too */
+ /* Check the value here */
+ if (codepoint = 0xd800 codepoint = 0xdfff)
+ return bad_offset;
+ if (codepoint 0x10)
+ return bad_offset;
+ if ((codepoint 0x1e) == 0xfffe)
+ return bad_offset;
}
return -1;
}
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index 37ddabb..16ed707 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -39,6 +39,15 @@ test_expect_failure 'UTF-16 refused because of NULs' '
git commit -a -F $TEST_DIRECTORY/t3900/UTF-16.txt
'
+test_expect_success 'UTF-8 invalid characters refused' '
+ rm -f $HOME/stderr
+ echo UTF-8 characters F
+ git commit -a -F $TEST_DIRECTORY/t3900/UTF-8-invalid.txt \
+ 2$HOME/stderr
+ grep did not conform $HOME/stderr
+'
+
+rm -f $HOME/stderr
for H in ISO8859-1 eucJP ISO-2022-JP
do
diff --git a/t/t3900/UTF-8-invalid.txt b/t/t3900/UTF-8-invalid.txt
new file mode 100644
index 000..343684d
--- /dev/null
+++ b/t/t3900/UTF-8-invalid.txt
@@ -0,0 +1,3 @@
+Commit message
+
+Invalid surrogate:???
--
1.8.3.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
[PATCH 2/2] commit: reject overlong UTF-8 sequences
The commit code accepts pseudo-UTF-8 sequences that encode a character with more
bytes than necessary. Reject such sequences, since they are not valid UTF-8.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
commit.c | 14 --
t/t3900-i18n-commit.sh | 8
t/t3900/UTF-8-overlong.txt | 3 +++
3 files changed, 23 insertions(+), 2 deletions(-)
create mode 100644 t/t3900/UTF-8-overlong.txt
diff --git a/commit.c b/commit.c
index 2280413..e57fec6 100644
--- a/commit.c
+++ b/commit.c
@@ -1240,11 +1240,15 @@ int commit_tree(const struct strbuf *msg, unsigned char
*tree,
static int find_invalid_utf8(const char *buf, int len)
{
int offset = 0;
+ static const unsigned int max_codepoint[] = {
+ 0x7f, 0x7ff, 0x, 0x1f
+ };
while (len) {
unsigned char c = *buf++;
int bytes, bad_offset;
unsigned int codepoint;
+ unsigned int min_val, max_val;
len--;
offset++;
@@ -1273,8 +1277,12 @@ static int find_invalid_utf8(const char *buf, int len)
if (len bytes)
return bad_offset;
- /* Place the encoded bits at the bottom of the value. */
+ /* Place the encoded bits at the bottom of the value and
compute the
+* valid range.
+*/
codepoint = (c 0x7f) bytes;
+ min_val = max_codepoint[bytes-1] + 1;
+ max_val = max_codepoint[bytes];
offset += bytes;
len -= bytes;
@@ -1287,13 +1295,15 @@ static int find_invalid_utf8(const char *buf, int len)
return bad_offset;
} while (--bytes);
- /* Check the value here */
+ /* Check the value and length here */
if (codepoint = 0xd800 codepoint = 0xdfff)
return bad_offset;
if (codepoint 0x10)
return bad_offset;
if ((codepoint 0x1e) == 0xfffe)
return bad_offset;
+ if (codepoint min_val || codepoint max_val)
+ return bad_offset;
}
return -1;
}
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index 16ed707..de0fcef 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -47,6 +47,14 @@ test_expect_success 'UTF-8 invalid characters refused' '
grep did not conform $HOME/stderr
'
+test_expect_success 'UTF-8 overlong sequences rejected' '
+ rm -f $HOME/stderr
+ echo UTF-8 overlong F
+ git commit -a -F $TEST_DIRECTORY/t3900/UTF-8-overlong.txt \
+ 2$HOME/stderr
+ grep did not conform $HOME/stderr
+'
+
rm -f $HOME/stderr
for H in ISO8859-1 eucJP ISO-2022-JP
diff --git a/t/t3900/UTF-8-overlong.txt b/t/t3900/UTF-8-overlong.txt
new file mode 100644
index 000..fa157e9
--- /dev/null
+++ b/t/t3900/UTF-8-overlong.txt
@@ -0,0 +1,3 @@
+???ommit message
+
+This is not a space:??
--
1.8.3.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
Re: [PATCH v2 0/4] Update linux-2.6.git location and related examples
On Sat, Jun 22, 2013 at 10:46:23AM -0400, W. Trevor King wrote: David and Junio mentioned that I'd missed a few 2.6 references in my initial pass. Here's a second attempt that does some deeper reworking of the effected sections. No comments after a week, so I'm giving this patch series a bump ;). Thanks, Trevor signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/4] Update linux-2.6.git location and related examples
W. Trevor King wk...@tremily.us writes: On Sat, Jun 22, 2013 at 10:46:23AM -0400, W. Trevor King wrote: David and Junio mentioned that I'd missed a few 2.6 references in my initial pass. Here's a second attempt that does some deeper reworking of the effected sections. No comments after a week, so I'm giving this patch series a bump ;). Hmph, didn't I queue them on 'pu' already? -- 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] perf-lib: fix start/stop of perf tests
Thanks, both. Will queue. -- 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: reject invalid UTF-8 codepoints
brian m. carlson sand...@crustytoothpaste.net writes:
The commit code already contains code for validating UTF-8, but it
does not check for invalid values, such as guaranteed
non-characters and surrogates. Fix this by explicitly checking
for and rejecting such characters.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Does this correspond to the following comment in the same file, and
if so, shouldn't this part of your patch?
diff --git a/commit.c b/commit.c
index 888e02a..8ce20d5 100644
--- a/commit.c
+++ b/commit.c
@@ -1292,8 +1292,8 @@ static int find_invalid_utf8(const char *buf, int len)
* If it isn't, it assumes any non-utf8 characters are Latin1,
* and does the conversion.
*
- * Fixme: we should probably also disallow overlong forms and
- * invalid characters. But we don't do that currently.
+ * Fixme: we should probably also disallow overlong forms.
+ * But we don't do that fully, yet.
*/
static int verify_utf8(struct strbuf *buf)
{
@@ -1264,24 +1265,35 @@ static int find_invalid_utf8(const char *buf, int len)
bytes++;
}
- /* Must be between 1 and 5 more bytes */
- if (bytes 1 || bytes 5)
+ /* Must be between 1 and 3 more bytes */
+ if (bytes 1 || bytes 3)
return bad_offset;
We used to allow te original up-to-6 form and this update is about
rejecting anything above U+10 (in line with e.g. RFC 3629)?
/* Do we *have* that many bytes? */
if (len bytes)
return bad_offset;
+ /* Place the encoded bits at the bottom of the value. */
+ codepoint = (c 0x7f) bytes;
+
offset += bytes;
len -= bytes;
/* And verify that they are good continuation bytes */
do {
+ codepoint = 6;
+ codepoint |= *buf 0x3f;
if ((*buf++ 0xc0) != 0x80)
return bad_offset;
} while (--bytes);
- /* We could/should check the value and length here too */
+ /* Check the value here */
+ if (codepoint = 0xd800 codepoint = 0xdfff)
+ return bad_offset;
As you use separate if statements for this check, perhaps you can
give each of them a better comment to say what each is rejecting?
E.g.
/* do not allow range for surrogate pair */
if (codepoint = 0xd800 codepoint = 0xdfff)
return bad_offset;
+ if (codepoint 0x10)
+ return bad_offset;
+ if ((codepoint 0x1e) == 0xfffe)
+ return bad_offset;
As that comment I quoted at the beginning says, we did not check for
invalid encoded values and the primary reason for it is beccause
this function did not want to look into the actual values here. But
now you are looking into codepoint, you can now also check for
overlong form (e.g. sequence C0 80 turning into U+)?
}
return -1;
}
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index 37ddabb..16ed707 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -39,6 +39,15 @@ test_expect_failure 'UTF-16 refused because of NULs' '
git commit -a -F $TEST_DIRECTORY/t3900/UTF-16.txt
'
+test_expect_success 'UTF-8 invalid characters refused' '
+ rm -f $HOME/stderr
+ echo UTF-8 characters F
+ git commit -a -F $TEST_DIRECTORY/t3900/UTF-8-invalid.txt \
+ 2$HOME/stderr
+ grep did not conform $HOME/stderr
+'
+
+rm -f $HOME/stderr
Perhaps
test_expect_success 'test name' '
test_when_finished rm -f $HOME/stderr
rm -f $HOME/stderr
echo ...
grep did not conform ...
'
diff --git a/t/t3900/UTF-8-invalid.txt b/t/t3900/UTF-8-invalid.txt
new file mode 100644
index 000..343684d
--- /dev/null
+++ b/t/t3900/UTF-8-invalid.txt
@@ -0,0 +1,3 @@
+Commit message
+
+Invalid surrogate:???
I suspect that I did not receive what you intended to send. Do you
want to send this part as a binary patch perhaps?
--
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: reject invalid UTF-8 codepoints
On Sat, Jun 29, 2013 at 07:13:40PM -0700, Junio C Hamano wrote: brian m. carlson sand...@crustytoothpaste.net writes: Does this correspond to the following comment in the same file, and if so, shouldn't this part of your patch? Yes, yes, it should. We used to allow te original up-to-6 form and this update is about rejecting anything above U+10 (in line with e.g. RFC 3629)? Correct. Since no codepoints above U+10 will ever be assigned, there's no point in trying to allow those UTF-8 sequences, since they will be caught below anyway. Some four-byte sequences will produce too-large codepoints, but all five- and six-byte sequences are guaranteed to. As you use separate if statements for this check, perhaps you can give each of them a better comment to say what each is rejecting? E.g. /* do not allow range for surrogate pair */ if (codepoint = 0xd800 codepoint = 0xdfff) return bad_offset; Sure. As that comment I quoted at the beginning says, we did not check for invalid encoded values and the primary reason for it is beccause this function did not want to look into the actual values here. But now you are looking into codepoint, you can now also check for overlong form (e.g. sequence C0 80 turning into U+)? Correct. That's what my second patch does. I thought I would make the changes separately, since they're slightly different and from what I've seen git development prefers small, independent patches, but if you'd prefer, I can squash them into one patch. Perhaps test_expect_success 'test name' ' test_when_finished rm -f $HOME/stderr I wasn't aware that existed, but it makes sense to use it. +Invalid surrogate:??? I suspect that I did not receive what you intended to send. Do you want to send this part as a binary patch perhaps? If you ended up with an encoding of U+D800, then you got it. Otherwise, I can resend it as a binary patch during the reroll. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
