[PATCH 0/3] fix cloning superprojects from .
Hi, On Fri, Nov 09, 2012 at 07:42:26PM +0100, Heiko Voigt wrote: Since this is a change in behaviour I would like to further think about the implications this brings if we fix this. Not sure how many people clone from .. The correct behavior (as documented) is the one you introduce with your patch. If we decide to fix this we should also correct the path calculation in git-submodule.sh. Ok I think this corner case is not that commonly used since most people work with remote remotes which you can not cd into to clone from .. Here is a patch series to clean this handling up. Cheers Heiko Heiko Voigt (3): Fix relative submodule setup of submodule tests ensure that relative submodule url needs ./ or ../ fix corner case for relative submodule path calculation git-submodule.sh | 22 + t/t7400-submodule-basic.sh | 56 t/t7403-submodule-sync.sh| 2 ++ t/t7406-submodule-update.sh | 2 ++ t/t7407-submodule-foreach.sh | 2 ++ t/t7506-status-submodule.sh | 2 ++ 6 files changed, 86 insertions(+) -- 1.8.0.3.gaed4666 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ensure that relative submodule url needs ./ or ../
Even though a relative path can be without them the documentation explicitely talks about them. Lets ensure that behavior with a test. Signed-off-by: Heiko Voigt hvo...@hvoigt.net --- t/t7400-submodule-basic.sh | 12 1 file changed, 12 insertions(+) diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh index 5397037..3c2afa6 100755 --- a/t/t7400-submodule-basic.sh +++ b/t/t7400-submodule-basic.sh @@ -506,6 +506,18 @@ test_expect_success 'set up for relative path tests' ' ) ' +test_expect_success 'subrepo is NOT considered a relative path' ' + ( + cd reltest + cp pristine-.git-config .git/config + cp pristine-.gitmodules .gitmodules + git config -f .gitmodules submodule.sub.url subrepo + git config remote.origin.url $submodurl + git submodule init + test $(git config submodule.sub.url) = subrepo + ) +' + test_expect_success '../subrepo works with URL - ssh://hostname/repo' ' ( cd reltest -- 1.8.0.3.gaed4666 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Fix relative submodule setup of submodule tests
If a remote is configured in a superproject relative submodule urls should be relative to that remote. Since we have a bug in relative path calculation for superproject paths that contain a /. using ../submodule was accepted here. We are going to fix this behavior so we first need to correct these tests. Later tests expect the submodules origin to be in a directory underneath the tests root. Lets remove the origin from super (which points directly at the tests root directory) to keep these tests expectations. Signed-off-by: Heiko Voigt hvo...@hvoigt.net --- t/t7403-submodule-sync.sh| 2 ++ t/t7406-submodule-update.sh | 2 ++ t/t7407-submodule-foreach.sh | 2 ++ t/t7506-status-submodule.sh | 2 ++ 4 files changed, 8 insertions(+) diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh index 524d5c1..b310a58 100755 --- a/t/t7403-submodule-sync.sh +++ b/t/t7403-submodule-sync.sh @@ -18,6 +18,8 @@ test_expect_success setup ' git clone . super git clone super submodule (cd super +# relative submodule urls relate to this folder not the remotes +git remote rm origin git submodule add ../submodule submodule test_tick git commit -m submodule diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index 1542653..f3628c9 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -32,6 +32,8 @@ test_expect_success 'setup a submodule tree' ' git clone super merging git clone super none (cd super +# relative submodule urls relate to this folder not the remotes +git remote rm origin git submodule add ../submodule submodule test_tick git commit -m submodule diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh index 9b69fe2..99956a6 100755 --- a/t/t7407-submodule-foreach.sh +++ b/t/t7407-submodule-foreach.sh @@ -21,6 +21,8 @@ test_expect_success 'setup a submodule tree' ' git clone super submodule ( cd super + # relative submodule urls relate to this folder not the remotes + git remote rm origin git submodule add ../submodule sub1 git submodule add ../submodule sub2 git submodule add ../submodule sub3 diff --git a/t/t7506-status-submodule.sh b/t/t7506-status-submodule.sh index d31b34d..9021b1a 100755 --- a/t/t7506-status-submodule.sh +++ b/t/t7506-status-submodule.sh @@ -203,6 +203,8 @@ test_expect_success 'status with merge conflict in .gitmodules' ' test_create_repo_with_commit sub2 ( cd super + # relative submodule urls relate to this folder not the remotes + git remote rm origin prev=$(git rev-parse HEAD) git checkout -b add_sub1 git submodule add ../sub1 -- 1.8.0.3.gaed4666 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] fix corner case for relative submodule path calculation
A trailing /. for the superprojects origin is treated as
a full path component. This is wrong. Lets add a test and
fix this.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
git-submodule.sh | 22 ++
t/t7400-submodule-basic.sh | 44
2 files changed, 66 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..9f61a9c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -69,6 +69,28 @@ resolve_relative_url ()
;;
esac
+ # strip one dot path components
+ tempurl=$remoteurl
+ remoteurl=
+ sep=
+ while test -n $tempurl
+ do
+ case $tempurl in
+ */.)
+ tempurl=${tempurl%/.}
+ ;;
+ ?*/*)
+ remoteurl=${tempurl##*/}$sep$remoteurl
+ tempurl=${tempurl%/*}
+ sep=/
+ ;;
+ *)
+ remoteurl=$tempurl$sep$remoteurl
+ tempurl=
+ ;;
+ esac
+ done
+
while test -n $url
do
case $url in
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 3c2afa6..1b4cc00 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -518,6 +518,50 @@ test_expect_success 'subrepo is NOT considered a relative
path' '
)
'
+test_expect_success '../subrepo works with absolute local path -
$submodurl/repo/.' '
+ (
+ cd reltest
+ cp pristine-.git-config .git/config
+ cp pristine-.gitmodules .gitmodules
+ git config remote.origin.url $submodurl/repo/.
+ git submodule init
+ test $(git config submodule.sub.url) = $submodurl/subrepo
+ )
+'
+
+test_expect_success '../subrepo works with absolute local path -
$submodurl/repo/./' '
+ (
+ cd reltest
+ cp pristine-.git-config .git/config
+ cp pristine-.gitmodules .gitmodules
+ git config remote.origin.url $submodurl/repo/./
+ git submodule init
+ test $(git config submodule.sub.url) = $submodurl/subrepo
+ )
+'
+
+test_expect_success '../subrepo works with absolute local path -
$submodurl/./repo/.' '
+ (
+ cd reltest
+ cp pristine-.git-config .git/config
+ cp pristine-.gitmodules .gitmodules
+ git config remote.origin.url $submodurl/./repo/.
+ git submodule init
+ test $(git config submodule.sub.url) = $submodurl/subrepo
+ )
+'
+
+test_expect_success '../subrepo works with absolute local path -
$submodurl/././repo/.' '
+ (
+ cd reltest
+ cp pristine-.git-config .git/config
+ cp pristine-.gitmodules .gitmodules
+ git config remote.origin.url $submodurl/././repo/.
+ git submodule init
+ test $(git config submodule.sub.url) = $submodurl/subrepo
+ )
+'
+
test_expect_success '../subrepo works with URL - ssh://hostname/repo' '
(
cd reltest
--
1.8.0.3.gaed4666
--
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] send-email: add proper default sender
On Tue, Nov 13, 2012 at 8:47 AM, Jeff King p...@peff.net wrote: But I still don't see how that has anything to do with what send-email does or should do. That is why I said strawman above. You seem to think I am saying that send-email should use the system that generated those broken names, when I am saying the opposite. No, I'm saying none should use that system, and that in fact 'git commit' should be stricter... both should be stricter. Those people would also not be using a new version of git-send-email, and it will always prompt. I thought we were talking about what send-email should do in future versions. Namely, loosening that safety valve (the prompt) because it is inconvenient, but tightening the checks so that losing the safety valve is not a problem. Yeah, but all I'm saying is that the issue happens, you seemed to suggest that it doesn't. I'm not talking about git send-email, I'm talking about your comment 'it has always been the case that you can use git without setting user.*', which has caused issues with wrong author/commmitter names in commits, and will probably continue to do so. The second half of that sentence that you quoted above is ...instead only using the environment. As in, environment variables like GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL, and EMAIL. _Not_ implicit generation of the email from the username and hostname. That sentence was *not* about 'git send-email', it was about git in general, and 'git commit' is perfectly happy with implicit generation of the email from the username and hostname. I don't thin 'git commit' should do that, and I don't think 'git send-email' should do that. I'm criticizing the whole approach. I am tempted to fault myself for not communicating well, but I feel like I have made that point at least 3 times in this conversation now. Is that the source of the confusion? I think you are the one that is not understanding what I'm saying. But I don't think it matters. This is what I'm saying; the current situation with 'git commit' is not OK, _both_ 'git commit' and 'git send-email' should change. And you will survive if upstream git (whether it is me today or Junio tomorrow) does not pick up your patch. Indeed I would, but there's other people that would benefit from this patch. I'm sure I'm not the only person that doesn't have sendmail.from configured, but does have user.name/user.email, and is constantly typing enter. And the difference is that I'm _real_, the hypothetical user that sends patches with GIT_AUTHOR_NAME/EMAIL is not. I would be convinced otherwise if some evidence was presented that such a user is real though. I remember writing you a long email recently about how one of the responsibilities of the maintainer is to balance features versus regressions. I'll not bother repeating myself here. And to balance you need to *measure*, and that means taking into consideration who actually uses the features, if there's any. And it looks to me this is a feature nobody uses. But listen closely to what you said: I actually think it would make more sense to drop the prompt entirely and just die when the user has not given us a usable ident. Suppose somebody has a full name, and a fully qualified domain name, and he can receive mails to it directly. Such a user would not need a git configuration, and would not need $EMAIL, or anything. Currently 'git send-email' will throw 'Felipe Contreras feli...@felipec.org' which would actually work, but is not explicit. You are suggesting to break that use-case. You are introducing a regression. And this case is realistic, unlike the GIT_AUTHOR_NAME/EMAIL. Isn't it? I prefer to concentrate on real issues, but that's just me. As for whether they exist, what data do you have? What data do _you_ have? When there's no evidence either way, the rational response is to don't believe. That's the default position. Are you aware that the test suite, for example, relies on setting GIT_AUTHOR_NAME but not having any user.* config? What tests? My patch doesn't seem to break anything there: % make -C t t9001-send-email.sh # passed all 96 test(s) When somebody comes on the list and asks why every git program in the entire system respects GIT_* environment variables as an override to user.* configuration _except_ for send-email, what should I say? The same thing you say when somebody comes reporting a bug: yeah, we should probably fix that. But that's not going to happen. And in the unlikely event that it does, it's not going to be a major issue. It's all about proportion. Is it possible that we all are going to die tomorrow because of an asteroid? Sure... but what's the point of worrying about it if it's not likely? But let's look at the current situation closely: PERL5LIB=~/dev/git/perl ./git-send-email.perl --confirm=always -1 1) No information at all fatal: empty ident name (for felipec@nysa.(none)) not allowed That is dependent on your system. If
[PATCH 14/13] test-wildmatch: avoid Windows path mangling
On Windows, arguments starting with a forward slash is mangled as if
it were full pathname. This causes the patterns beginning with a slash
not to be passed to test-wildmatch correctly. Avoid mangling by never
accepting patterns starting with a slash. Those arguments must be
rewritten with a leading XXX (e.g. /abc becomes XXX/abc), which
will be removed by test-wildmatch itself before feeding the patterns
to wildmatch() or fnmatch().
Reported-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
On Sun, Nov 11, 2012 at 5:47 PM, Junio C Hamano gits...@pobox.com wrote:
The title taken together with the above explanation makes it sound
as if wildmatch code does not work with the pattern /foo on Windows
at all and to avoid the issue (instead of fixing the breakage) this
patch removes such tests
OK how about this?
t/t3070-wildmatch.sh | 10 +-
test-wildmatch.c | 8
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index e6ad6f4..3155eab 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -74,7 +74,7 @@ match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 0 'foo' '**/foo'
-match 1 x '/foo' '**/foo'
+match 1 x 'XXX/foo' '**/foo'
match 1 0 'bar/baz/foo' '**/foo'
match 0 0 'bar/baz/foo' '*/foo'
match 0 0 'foo/bar/baz' '**/bar*'
@@ -95,8 +95,8 @@ match 0 0 ']' '[!]-]'
match 1 x 'a' '[!]-]'
match 0 0 '' '\'
match 0 x '\' '\'
-match 0 x '/\' '*/\'
-match 1 x '/\' '*/\\'
+match 0 x 'XXX/\' '*/\'
+match 1 x 'XXX/\' '*/\\'
match 1 1 'foo' 'foo'
match 1 1 '@foo' '@foo'
match 0 0 'foo' '@foo'
@@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1'
'-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1'
'-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1'
'-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1'
'/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1'
'/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1'
'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1'
'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 74c0864..e384c8e 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -3,6 +3,14 @@
int main(int argc, char **argv)
{
+ int i;
+ for (i = 2; i argc; i++) {
+ if (argv[i][0] == '/')
+ die(Forward slash is not allowed at the beginning of
the\n
+ pattern because Windows does not like it. Use
`XXX/' instead.);
+ else if (!strncmp(argv[i], XXX/, 4))
+ argv[i] += 3;
+ }
if (!strcmp(argv[1], wildmatch))
return !!wildmatch(argv[3], argv[2], 0);
else if (!strcmp(argv[1], iwildmatch))
--
1.8.0.rc2.23.g1fb49df
--
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: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
Felipe Contreras venit, vidit, dixit 12.11.2012 23:47: On Mon, Nov 12, 2012 at 10:41 PM, Jeff King p...@peff.net wrote: On Sun, Nov 11, 2012 at 07:48:14PM +0100, Felipe Contreras wrote: 3. Exporters should not use it if they have any broken-down representation at all. Even knowing that the first half is a human name and the second half is something else would give it a better shot at cleaning than fast-import would get. I'm not sure what you mean by this. If they have name and email, then sure, it's easy. But not as easy as just printing it. What if you have this: name=Peff angle brackets King email=p...@peff.net Concatenating them does not produce a valid git author name. Sending the concatenation through fast-import's cleanup function would lose information (namely, the location of the boundary between name and email). Right. Unfortunately I'm not aware of any DSCM that does that. Similarly, one might have other structured data (e.g., CVS username) where the structure is a useful hint, but some conversion to name+email is still necessary. CVS might be the only one that has such structured data. I think in subversion the username has no meaning. A 'felipec' subversion username is as bad as a mercurial 'felipec' username. In subversion, the username has the clearly defined meaning of being a username on the subversion host. If the host is, e.g., a sourceforge site then I can easily look up the user profile and convert the username into a valid e-mail address (username@users.sf.net). That is the advantage that the exporter (together with user knowledge) has over the importer. If the initial clone process aborts after every single unknown user it's no fun, of course. On the other hand, if an incremental clone (fetch) let's commits with unknown author sneak in it's no fun either (because I may want to fetch in crontab and publish that converted beast automatically). That is why I proposed neither approach. Most conveniently, the export side of a remote helper would - do obvious automatic lossless transformations - use an author map for other names - For names not covered by the above (or having an empty map entry): Stop exporting commits but continue parsing commits and amend the author map with any unknown usernames (empty entry), and warn the user. (crontab script can notify me based on the return code.) If the cloning involves a foreign clone (like the hg clone behind the scene) then the runtime of the second pass should be much smaller. In principle, one could even store all blobs and trees on the first run and skip that step on the second, but that would rely on immutability on the foreign side, so I dunno. (And to check the sha1, we have to get the blob anyways.) As for the format for incomplete entries (foo some@where), a technical guideline should suffice for those that follow guidelines. 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: [PATCHv3] replace: parse revision argument for -d
Jeff King venit, vidit, dixit 12.11.2012 21:42:
On Mon, Nov 12, 2012 at 03:18:02PM +0100, Michael J Gruber wrote:
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the argument to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Notes:
v3 safeguards the hex buffer against reuse
Thanks, I don't see any other functional problems.
diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..33e6ec3 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,28 @@ typedef int (*each_replace_name_fn)(const char *name,
const char *ref,
static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
{
-const char **p;
+const char **p, *q;
I find this readable today, but I wonder if in six months we will wonder
what in the world q means. Maybe short_refname or something would be
appropriate?
That would be sooo inappropriate! ;)
Maybe full_hex?
I should also do away with the first replacement which really made sense
in v1 only.
v4 to follow.
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
Notes in format-patch (was: Re: [PATCHv3] replace: parse revision argument for -d)
Michael J Gruber venit, vidit, dixit 12.11.2012 15:18: 'git replace' parses the revision arguments when it creates replacements (so that a sha1 can be abbreviated, e.g.) but not when deleting replacements. Make it parse the argument to 'replace -d' in the same way. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: v3 safeguards the hex buffer against reuse builtin/replace.c | 16 ++-- t/t6050-replace.sh | 11 +++ 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/builtin/replace.c b/builtin/replace.c By the way - Junio, is that the intented outcome of format-patch --notes? I would rather put the newline between the note and the diffstat (and omit the one after the ---) but may have goofed up a rebase: ... Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: v3 safeguards the hex buffer against reuse builtin/replace.c | 16 ++-- ... -- 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
[PATCHv4] replace: parse revision argument for -d
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the argument to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Notes:
v4 names the aux variable more concisely and does away with a superfluous
assignment.
builtin/replace.c | 15 +--
t/t6050-replace.sh | 11 +++
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..398ccd5 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,27 @@ typedef int (*each_replace_name_fn)(const char *name, const
char *ref,
static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
{
- const char **p;
+ const char **p, *full_hex;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
for (p = argv; *p; p++) {
- if (snprintf(ref, sizeof(ref), refs/replace/%s, *p)
- = sizeof(ref)) {
- error(replace ref name too long: %.*s..., 50, *p);
+ if (get_sha1(*p, sha1)) {
+ error(Failed to resolve '%s' as a valid ref., *p);
had_error = 1;
continue;
}
+ full_hex = sha1_to_hex(sha1);
+ snprintf(ref, sizeof(ref), refs/replace/%s, full_hex);
+ /* read_ref() may reuse the buffer */
+ full_hex = ref + strlen(refs/replace/);
if (read_ref(ref, sha1)) {
- error(replace ref '%s' not found., *p);
+ error(replace ref '%s' not found., full_hex);
had_error = 1;
continue;
}
- if (fn(*p, ref, sha1))
+ if (fn(full_hex, ref, sha1))
had_error = 1;
}
return had_error;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..decdc33 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -140,6 +140,17 @@ test_expect_success 'git replace replacing' '
test $HASH2 = $(git replace)
'
+test_expect_success 'git replace resolves sha1' '
+ SHORTHASH2=$(git rev-parse --short=8 $HASH2)
+ git replace -d $SHORTHASH2
+ git replace $SHORTHASH2 $R
+ git show $HASH2 | grep O Thor
+ test_must_fail git replace $HASH2 $R
+ git replace -f $HASH2 $R
+ test_must_fail git replace -f
+ test $HASH2 = $(git replace)
+'
+
# This creates a side branch where the bug in H2
# does not appear because P2 is created by applying
# H2 and squashing H5 into it.
--
1.8.0.311.gdd08018
--
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 nd/wildmatch] Correct Git's version of isprint and isspace
Git's ispace does not include 11 and 12. Git's isprint includes
control space characters (10-13). According to glibc-2.14.1 on C
locale on Linux, this is wrong. This patch fixes it.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
I wrote a small C program to compare the result of all is* functions
that Git replaces against the libc version. These are the only ones that
differ. Which matches what Jan Schönherr commented.
ctype.c | 6 +++---
git-compat-util.h | 11 ++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/ctype.c b/ctype.c
index 0bfebb4..71311a3 100644
--- a/ctype.c
+++ b/ctype.c
@@ -14,11 +14,11 @@ enum {
P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
X = GIT_CNTRL,
U = GIT_PUNCT,
- Z = GIT_CNTRL | GIT_SPACE
+ Z = GIT_CNTRL_SPACE
};
-const unsigned char sane_ctype[256] = {
- X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
+const unsigned int sane_ctype[256] = {
+ X, X, X, X, X, X, X, X, X, Z, Z, Z, Z, Z, X, X, /* 0.. 15 */
X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
diff --git a/git-compat-util.h b/git-compat-util.h
index 02f48f6..4ed3f94 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -474,8 +474,8 @@ extern const char tolower_trans_tbl[256];
#undef ispunct
#undef isxdigit
#undef isprint
-extern const unsigned char sane_ctype[256];
-#define GIT_SPACE 0x01
+extern const unsigned int sane_ctype[256];
+#define GIT_CNTRL_SPACE 0x01
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
#define GIT_GLOB_SPECIAL 0x08
@@ -483,9 +483,10 @@ extern const unsigned char sane_ctype[256];
#define GIT_PATHSPEC_MAGIC 0x20
#define GIT_CNTRL 0x40
#define GIT_PUNCT 0x80
-#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] (mask)) != 0)
+#define GIT_SPACE 0x100
+#define sane_istest(x,mask) ((sane_ctype[(unsigned int)(x)] (mask)) != 0)
#define isascii(x) (((x) ~0x7f) == 0)
-#define isspace(x) sane_istest(x,GIT_SPACE)
+#define isspace(x) sane_istest(x,GIT_SPACE | GIT_CNTRL_SPACE)
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
@@ -493,7 +494,7 @@ extern const unsigned char sane_ctype[256];
#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
-#define iscntrl(x) (sane_istest(x,GIT_CNTRL))
+#define iscntrl(x) (sane_istest(x,GIT_CNTRL | GIT_CNTRL_SPACE))
#define ispunct(x) sane_istest(x, GIT_PUNCT | GIT_REGEX_SPECIAL | \
GIT_GLOB_SPECIAL | GIT_PATHSPEC_MAGIC)
#define isxdigit(x) (hexval_table[x] != -1)
--
1.8.0.rc2.23.g1fb49df
--
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: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
Hi,
On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
Hi,
[...]
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
[...]
Thanks
Marc
---
contrib/completion/git-completion.bash | 53
+++-
contrib/completion/git-completion.tcsh | 34
2 files changed, 86 insertions(+), 1 deletions(-)
create mode 100755 contrib/completion/git-completion.tcsh
Please have a look at Documentation/SubmittingPatches to see how to
properly format the commit message, i.e. no greeting and sign-off in
the commit message part, and the S-o-b line should be the last before
the '---'.
Your patch seems to be severely line-wrapped. That document also
contains a few MUA-specific tips to help avoid that.
Other than that, it's a good description of the changes and
considerations. I agree that this approach seems to be the best from
the three.
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..6d4b57a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,4 +1,6 @@
-#!bash
+#!/bin/bash
+# The above line is important as this script can be executed when used
+# with another shell such as tcsh
See comment near the end.
#
# bash/zsh completion support for core Git.
#
@@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
if [ Cygwin = $(uname -o 2/dev/null) ]; then
__git_complete git.exe __git_main
fi
+
+# Method that will output the result of the completion done by
+# the bash completion script, so that it can be re-used in another
+# context than the bash complete command.
+# It accepts 1 to 2 arguments:
+# 1: The command-line to complete
+# 2: The index of the word within argument #1 in which the cursor is
+#located (optional). If parameter 2 is not provided, it will be
+#determined as best possible using parameter 1.
+_git_complete_with_output ()
+{
+ # Set COMP_WORDS to the command-line as bash would.
+ COMP_WORDS=($1)
That comment is only true for older Bash versions. Since v4 Bash
splits the command line at characters that the readline library treats
as word separators when performing word completion. But the
completion script has functions to deal with both, so this shouldn't
be a problem.
+
+ # Set COMP_CWORD to the cursor location as bash would.
+ if [ -n $2 ]; then
+ COMP_CWORD=$2
+ else
+ # Assume the cursor is at the end of parameter #1.
+ # We must check for a space as the last character which will
+ # tell us that the previous word is complete and the cursor
+ # is on the next word.
+ if [ ${1: -1} == ]; then
+ # The last character is a space, so our
location is at the end
+ # of the command-line array
+ COMP_CWORD=${#COMP_WORDS[@]}
+ else
+ # The last character is not a space, so our
location is on the
+ # last word of the command-line array, so we
must decrement the
+ # count by 1
+ COMP_CWORD=$((${#COMP_WORDS[@]}-1))
+ fi
+ fi
+
+ # Call _git() or _gitk() of the bash script, based on the first
+ # element of the command-line
+ _${COMP_WORDS[0]}
+
+ # Print the result that is stored in the bash variable ${COMPREPLY}
Really? ;)
I like the above comments about setting COMP_CWORD, because they
explain why you do what you do, which would be otherwise difficult to
figure out. But telling that an echo in a for loop over an array
prints that array is, well, probably not necessary.
+ for i in ${COMPREPLY[@]}; do
+ echo $i
+ done
There is no need for the loop here to print the array one element per
line:
local IFS=$'\n'
echo ${COMPREPLY[*]}
+}
+
+if [ -n $1 ] ; then
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
Where does the second argument come from? Below you run this script
as '${__git_tcsh_completion_script} ${COMMAND_LINE}', i.e. $2 is
never set. Am I missing something?
+fi
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100755
index 000..7b7baea
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,34 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# This script makes use of the git-completion.bash script to
+# determine the proper completion for git commands under tcsh.
+#
+# To use this completion script:
+#
+#1) Copy both
Simple question ? [Git branch]
Hi All Users, I am beginner in git. I am doing my first steps with this tool. Now, I used git gui on linux OS. I don't know what I could change branches ? I need to change current working branch to do a commit. I can see in the menu branch : Create checkout rebase Reset -- Could anyone help me please ? I would appreciate for any help. agatte -- View this message in context: http://git.661346.n2.nabble.com/Simple-question-Git-branch-tp7571115.html Sent from the git mailing list archive at Nabble.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: Notes in format-patch (was: Re: [PATCHv3] replace: parse revision argument for -d)
On Tue, Nov 13, 2012 at 11:30:19AM +0100, Michael J Gruber wrote: Michael J Gruber venit, vidit, dixit 12.11.2012 15:18: 'git replace' parses the revision arguments when it creates replacements (so that a sha1 can be abbreviated, e.g.) but not when deleting replacements. Make it parse the argument to 'replace -d' in the same way. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: v3 safeguards the hex buffer against reuse builtin/replace.c | 16 ++-- t/t6050-replace.sh | 11 +++ 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/builtin/replace.c b/builtin/replace.c By the way - Junio, is that the intented outcome of format-patch --notes? I would rather put the newline between the note and the diffstat (and omit the one after the ---) but may have goofed up a rebase: I do not know was intended, but the above quoted output is hard to read, and your suggested change looks way better. -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: Reviews on mailing-list
On Mon, Nov 12, 2012 at 4:15 AM, David Lang da...@lang.hm wrote: Using a web browser requires connectivity at the time you are doing the review. Mailing list based reviews can be done at times when you don't have connectivity. I am not against email-based reviews but I'd like to point out that with Google Gears (and HTML5 Storage?) Gerrit can be made work offline too. I don't know how much work required though. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4] replace: parse revision argument for -d
On Tue, Nov 13, 2012 at 11:34:11AM +0100, Michael J Gruber wrote: 'git replace' parses the revision arguments when it creates replacements (so that a sha1 can be abbreviated, e.g.) but not when deleting replacements. Make it parse the argument to 'replace -d' in the same way. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: v4 names the aux variable more concisely and does away with a superfluous assignment. Thanks. I agree the name full_hex is much better. Patch looks good to me at this point. -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
[PATCH 0/5] win32: support echo for terminal-prompt
We currently only support getpass, which does not echo at all, for git_terminal_prompt on Windows. The Windows console is perfectly capable of doing this, so let's make it so. This implementation tries to reuse the /dev/tty-code as much as possible. The big reason that this becomes a bit hairy is that Ctrl+C needs to be handled correctly, so we don't leak the console state to a non-echoing setting when a user aborts. Windows makes this bit a little bit tricky, in that we need to implement SIGINT for fgetc. However, I suspect that this is a good thing to do in the first place. An earlier iteration was also breifly discussed here: http://mid.gmane.org/cabpqnsaucedu4+2n63n0k_xwsxop_ifzg3geyspsbpcsvv8...@mail.gmail.com The series can also be found here, only with an extra patch that makes the (interactive) testing a bit easier: https://github.com/kusma/git/tree/work/terminal-cleanup Erik Faye-Lund (5): mingw: make fgetc raise SIGINT if apropriate compat/terminal: factor out echo-disabling compat/terminal: separate input and output handles mingw: reuse tty-version of git_terminal_prompt mingw: get rid of getpass implementation compat/mingw.c| 91 +++--- compat/mingw.h| 8 +++- compat/terminal.c | 129 -- 3 files changed, 169 insertions(+), 59 deletions(-) -- 1.8.0.7.gbeffeda -- 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/RFC 0/5] win32: support echo for terminal-prompt
We currently only support getpass, which does not echo at all, for git_terminal_prompt on Windows. The Windows console is perfectly capable of doing this, so let's make it so. This implementation tries to reuse the /dev/tty-code as much as possible. The big reason that this becomes a bit hairy is that Ctrl+C needs to be handled correctly, so we don't leak the console state to a non-echoing setting when a user aborts. Windows makes this bit a little bit tricky, in that we need to implement SIGINT for fgetc. However, I suspect that this is a good thing to do in the first place. An earlier iteration was also breifly discussed here: http://mid.gmane.org/cabpqnsaucedu4+2n63n0k_xwsxop_ifzg3geyspsbpcsvv8...@mail.gmail.com The series can also be found here, only with an extra patch that makes the (interactive) testing a bit easier: https://github.com/kusma/git/tree/work/terminal-cleanup Erik Faye-Lund (5): mingw: make fgetc raise SIGINT if apropriate compat/terminal: factor out echo-disabling compat/terminal: separate input and output handles mingw: reuse tty-version of git_terminal_prompt mingw: get rid of getpass implementation compat/mingw.c| 91 +++--- compat/mingw.h| 8 +++- compat/terminal.c | 129 -- 3 files changed, 169 insertions(+), 59 deletions(-) -- 1.8.0.7.gbeffeda -- 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/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
Set a control-handler to prevent the process from terminating, and
simulate SIGINT so it can be handled by a signal-handler as usual.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
compat/mingw.c | 76 ++
compat/mingw.h | 6 +
2 files changed, 72 insertions(+), 10 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 78e8f54..33ddfdf 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -319,6 +319,31 @@ ssize_t mingw_write(int fd, const void *buf, size_t count)
return write(fd, buf, min(count, 31 * 1024 * 1024));
}
+static BOOL WINAPI ctrl_ignore(DWORD type)
+{
+ return TRUE;
+}
+
+#undef fgetc
+int mingw_fgetc(FILE *stream)
+{
+ int ch;
+ if (!isatty(_fileno(stream)))
+ return fgetc(stream);
+
+ SetConsoleCtrlHandler(ctrl_ignore, TRUE);
+ while (1) {
+ ch = fgetc(stream);
+ if (ch != EOF || GetLastError() != ERROR_OPERATION_ABORTED)
+ break;
+
+ /* Ctrl+C was pressed, simulate SIGINT and retry */
+ mingw_raise(SIGINT);
+ }
+ SetConsoleCtrlHandler(ctrl_ignore, FALSE);
+ return ch;
+}
+
#undef fopen
FILE *mingw_fopen (const char *filename, const char *otype)
{
@@ -1524,7 +1549,7 @@ static HANDLE timer_event;
static HANDLE timer_thread;
static int timer_interval;
static int one_shot;
-static sig_handler_t timer_fn = SIG_DFL;
+static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;
/* The timer works like this:
* The thread, ticktack(), is a trivial routine that most of the time
@@ -1538,13 +1563,7 @@ static sig_handler_t timer_fn = SIG_DFL;
static unsigned __stdcall ticktack(void *dummy)
{
while (WaitForSingleObject(timer_event, timer_interval) ==
WAIT_TIMEOUT) {
- if (timer_fn == SIG_DFL) {
- if (isatty(STDERR_FILENO))
- fputs(Alarm clock\n, stderr);
- exit(128 + SIGALRM);
- }
- if (timer_fn != SIG_IGN)
- timer_fn(SIGALRM);
+ mingw_raise(SIGALRM);
if (one_shot)
break;
}
@@ -1635,12 +1654,49 @@ int sigaction(int sig, struct sigaction *in, struct
sigaction *out)
sig_handler_t mingw_signal(int sig, sig_handler_t handler)
{
sig_handler_t old = timer_fn;
- if (sig != SIGALRM)
+
+ switch (sig) {
+ case SIGALRM:
+ timer_fn = handler;
+ break;
+
+ case SIGINT:
+ sigint_fn = handler;
+ break;
+
+ default:
return signal(sig, handler);
- timer_fn = handler;
+ }
+
return old;
}
+#undef raise
+int mingw_raise(int sig)
+{
+ switch (sig) {
+ case SIGALRM:
+ if (timer_fn == SIG_DFL) {
+ if (isatty(STDERR_FILENO))
+ fputs(Alarm clock\n, stderr);
+ exit(128 + SIGALRM);
+ } else if (timer_fn != SIG_IGN)
+ timer_fn(SIGALRM);
+ return 0;
+
+ case SIGINT:
+ if (sigint_fn == SIG_DFL)
+ exit(128 + SIGINT);
+ else if (sigint_fn != SIG_IGN)
+ sigint_fn(SIGINT);
+ return 0;
+
+ default:
+ return raise(sig);
+ }
+}
+
+
static const char *make_backslash_path(const char *path)
{
static char buf[PATH_MAX + 1];
diff --git a/compat/mingw.h b/compat/mingw.h
index 61a6521..6b9e69a 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -179,6 +179,9 @@ int mingw_open (const char *filename, int oflags, ...);
ssize_t mingw_write(int fd, const void *buf, size_t count);
#define write mingw_write
+int mingw_fgetc(FILE *stream);
+#define fgetc mingw_fgetc
+
FILE *mingw_fopen (const char *filename, const char *otype);
#define fopen mingw_fopen
@@ -287,6 +290,9 @@ static inline unsigned int git_ntohl(unsigned int x)
sig_handler_t mingw_signal(int sig, sig_handler_t handler);
#define signal mingw_signal
+int mingw_raise(int sig);
+#define raise mingw_raise
+
/*
* ANSI emulation wrappers
*/
--
1.8.0.7.gbeffeda
--
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/RFC 3/5] compat/terminal: separate input and output handles
On Windows, the terminal cannot be opened in read-write mode, so
we need distinct pairs for reading and writing. Since this works
fine on other platforms as well, always open them in pairs.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
compat/terminal.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/compat/terminal.c b/compat/terminal.c
index 3217838..4a1fd3d 100644
--- a/compat/terminal.c
+++ b/compat/terminal.c
@@ -50,29 +50,36 @@ char *git_terminal_prompt(const char *prompt, int echo)
{
static struct strbuf buf = STRBUF_INIT;
int r;
- FILE *fh;
+ FILE *input_fh, *output_fh;
- fh = fopen(/dev/tty, w+);
- if (!fh)
+ input_fh = fopen(/dev/tty, r);
+ if (!input_fh)
return NULL;
+ output_fh = fopen(/dev/tty, w);
+ if (!output_fh) {
+ fclose(input_fh);
+ return NULL;
+ }
+
if (!echo disable_echo()) {
- fclose(fh);
+ fclose(input_fh);
+ fclose(output_fh);
return NULL;
}
- fputs(prompt, fh);
- fflush(fh);
+ fputs(prompt, output_fh);
+ fflush(output_fh);
- r = strbuf_getline(buf, fh, '\n');
+ r = strbuf_getline(buf, input_fh, '\n');
if (!echo) {
- fseek(fh, SEEK_CUR, 0);
- putc('\n', fh);
- fflush(fh);
+ putc('\n', output_fh);
+ fflush(output_fh);
}
restore_term();
- fclose(fh);
+ fclose(input_fh);
+ fclose(output_fh);
if (r == EOF)
return NULL;
--
1.8.0.7.gbeffeda
--
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/RFC 4/5] mingw: reuse tty-version of git_terminal_prompt
The getpass-implementation we use on Windows isn't at all ideal;
it works in raw-mode (as opposed to cooked mode), and as a result
does not deal correcly with deletion, arrow-keys etc.
Instead, use cooked mode to read a line at the time, allowing the
C run-time to process the input properly.
Since we set files to be opened in binary-mode by default on
Windows, introduce a FORCE_TEXT macro that expands to the t
modifier that forces the terminal to be opened in text-mode so we
do not have to deal with CRLF issues.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
compat/terminal.c | 69 +++
1 file changed, 60 insertions(+), 9 deletions(-)
diff --git a/compat/terminal.c b/compat/terminal.c
index 4a1fd3d..ce0fbd9 100644
--- a/compat/terminal.c
+++ b/compat/terminal.c
@@ -3,8 +3,22 @@
#include sigchain.h
#include strbuf.h
+#if defined(HAVE_DEV_TTY) || defined(WIN32)
+
+static void restore_term(void);
+
+static void restore_term_on_signal(int sig)
+{
+ restore_term();
+ sigchain_pop(sig);
+ raise(sig);
+}
+
#ifdef HAVE_DEV_TTY
+#define INPUT_PATH /dev/tty
+#define OUTPUT_PATH /dev/tty
+
static int term_fd = -1;
static struct termios old_term;
@@ -18,13 +32,6 @@ static void restore_term(void)
term_fd = -1;
}
-static void restore_term_on_signal(int sig)
-{
- restore_term();
- sigchain_pop(sig);
- raise(sig);
-}
-
static int disable_echo()
{
struct termios t;
@@ -46,17 +53,61 @@ error:
return -1;
}
+#elif defined(WIN32)
+
+#define INPUT_PATH CONIN$
+#define OUTPUT_PATH CONOUT$
+#define FORCE_TEXT t
+
+static HANDLE hconin = INVALID_HANDLE_VALUE;
+static DWORD cmode;
+
+static void restore_term(void)
+{
+ if (hconin == INVALID_HANDLE_VALUE)
+ return;
+
+ SetConsoleMode(hconin, cmode);
+ CloseHandle(hconin);
+ hconin = INVALID_HANDLE_VALUE;
+}
+
+static int disable_echo(void)
+{
+ hconin = CreateFile(CONIN$, GENERIC_READ | GENERIC_WRITE,
+ FILE_SHARE_READ, NULL, OPEN_EXISTING,
+ FILE_ATTRIBUTE_NORMAL, NULL);
+ if (hconin == INVALID_HANDLE_VALUE)
+ return -1;
+
+ GetConsoleMode(hconin, cmode);
+ sigchain_push_common(restore_term_on_signal);
+ if (!SetConsoleMode(hconin, cmode (~ENABLE_ECHO_INPUT))) {
+ CloseHandle(hconin);
+ hconin = INVALID_HANDLE_VALUE;
+ return -1;
+ }
+
+ return 0;
+}
+
+#endif
+
+#ifndef FORCE_TEXT
+#define FORCE_TEXT
+#endif
+
char *git_terminal_prompt(const char *prompt, int echo)
{
static struct strbuf buf = STRBUF_INIT;
int r;
FILE *input_fh, *output_fh;
- input_fh = fopen(/dev/tty, r);
+ input_fh = fopen(INPUT_PATH, r FORCE_TEXT);
if (!input_fh)
return NULL;
- output_fh = fopen(/dev/tty, w);
+ output_fh = fopen(OUTPUT_PATH, w FORCE_TEXT);
if (!output_fh) {
fclose(input_fh);
return NULL;
--
1.8.0.7.gbeffeda
--
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/RFC 5/5] mingw: get rid of getpass implementation
There's no remaining call-sites, and as pointed out in the
previous commit message, it's not quite ideal. So let's just
lose it.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
compat/mingw.c | 15 ---
compat/mingw.h | 2 --
2 files changed, 17 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 33ddfdf..5fc14b7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1758,21 +1758,6 @@ int link(const char *oldpath, const char *newpath)
return 0;
}
-char *getpass(const char *prompt)
-{
- struct strbuf buf = STRBUF_INIT;
-
- fputs(prompt, stderr);
- for (;;) {
- char c = _getch();
- if (c == '\r' || c == '\n')
- break;
- strbuf_addch(buf, c);
- }
- fputs(\n, stderr);
- return strbuf_detach(buf, NULL);
-}
-
pid_t waitpid(pid_t pid, int *status, int options)
{
HANDLE h = OpenProcess(SYNCHRONIZE | PROCESS_QUERY_INFORMATION,
diff --git a/compat/mingw.h b/compat/mingw.h
index 6b9e69a..f494ecb 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -55,8 +55,6 @@ struct passwd {
char *pw_dir;
};
-extern char *getpass(const char *prompt);
-
typedef void (__cdecl *sig_handler_t)(int);
struct sigaction {
sig_handler_t sa_handler;
--
1.8.0.7.gbeffeda
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] win32: support echo for terminal-prompt
Sorry, I messed up the subject (lacking RFC-prefix), so I aborted after sending the cover-letter. I'll resend with a proper prefix right away. On Tue, Nov 13, 2012 at 3:01 PM, Erik Faye-Lund kusmab...@gmail.com wrote: We currently only support getpass, which does not echo at all, for git_terminal_prompt on Windows. The Windows console is perfectly capable of doing this, so let's make it so. This implementation tries to reuse the /dev/tty-code as much as possible. The big reason that this becomes a bit hairy is that Ctrl+C needs to be handled correctly, so we don't leak the console state to a non-echoing setting when a user aborts. Windows makes this bit a little bit tricky, in that we need to implement SIGINT for fgetc. However, I suspect that this is a good thing to do in the first place. An earlier iteration was also breifly discussed here: http://mid.gmane.org/cabpqnsaucedu4+2n63n0k_xwsxop_ifzg3geyspsbpcsvv8...@mail.gmail.com The series can also be found here, only with an extra patch that makes the (interactive) testing a bit easier: https://github.com/kusma/git/tree/work/terminal-cleanup Erik Faye-Lund (5): mingw: make fgetc raise SIGINT if apropriate compat/terminal: factor out echo-disabling compat/terminal: separate input and output handles mingw: reuse tty-version of git_terminal_prompt mingw: get rid of getpass implementation compat/mingw.c| 91 +++--- compat/mingw.h| 8 +++- compat/terminal.c | 129 -- 3 files changed, 169 insertions(+), 59 deletions(-) -- 1.8.0.7.gbeffeda -- 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: [BUG] gitweb: XSS vulnerability of RSS feed
On Mon, Nov 12, 2012 at 3:24 PM, Jeff King p...@peff.net wrote:
On Mon, Nov 12, 2012 at 01:55:46PM -0500, Drew Northup wrote:
On Sun, Nov 11, 2012 at 6:28 PM, glpk xypron xypron.g...@gmx.de wrote:
Gitweb can be used to generate an RSS feed.
Arbitrary tags can be inserted into the XML document describing
the RSS feed by careful construction of the URL.
[...]
Something like this may be useful to defuse the file parameter, but
I presume a more definitive fix is in order...
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..af93e65 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1447,6 +1447,10 @@ sub validate_pathname {
if ($input =~ m!\0!) {
return undef;
}
+ # No XSS script/script inclusions
+ if ($input =~ m!(script)(.*)(/script)!){
+ return undef;
+ }
return $input;
}
This is the wrong fix for a few reasons:
1. It is on the input-validation side, whereas the real problem is on
the output-quoting side. Your patch means I could not access a file
called scriptfoo/script. What we really want is to have the
unquoted name internally, but then make sure we quote it when
outputting as part of an HTML (or XML) file.
I don't buy the argument that we don't need to clean up the input as
well. There are scant few of us that are going to name a file
scriptalert(Something Awful)/script in this world (I am
probably one of them). Input validation is key to keeping problems
like this from coming up repeatedly as those writing the guts of
programs are typically more interested in getting the assigned task
done and reporting the output to the user in a safe manner.
2. Script tags are only part of the problem. They are what make it
obviously a security vulnerability, but it is equally incorrect for
us to show the filename bfoo/b as bold. I would also not be
surprised if there are other cross-site attacks one can do without
using script.
Yes, there are. You are typically concerned with anything including
the following:
(1) Executable stuff;
(2) Out of nowhere resources that can reference executable stuff
(style / CSS, iframe, script includes);
(3) Media and other things that activate browser plugins directly.
3. Your filter is too simplistic. At the very least, it would not
filter out SCRIPT. I am not up to date on all of the
sneaking-around-HTML-filters attacks that are available these days,
but I wonder if one could also get around it using XML entities or
similar.
You will note that I said a more definitive fix is in order in my
original. In other words, I claimed it to be utterly incomplete to
start with. I wanted to get some thought going about input validation
(in particular since I am not a perl guru of any sort whatsoever--the
fair number of things I've written from scratch or mangled into shape
notwithstanding).
I think the right answer is going to be a well-placed call to esc_html.
This already happens automatically when we go through the CGI
element-building functions, but obviously we failed to make the call
when building the output manually. This is a great reason why template
languages which default to safe expansion should always be used.
Unfortunately, gitweb is living in 1995 in terms of web frameworks.
Escaping the output protects the user, but it DOES NOT protect the
server. We MUST handle both possibilities.
Besides, inserting one call to esc_html only fixes one attack path. I
didn't look to see if all others were already covered.
--
-Drew Northup
--
As opposed to vegetable or mineral error?
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
--
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
Commit message problem of reverting multiple commits
Hi, I ran git 1.8.0 command line git revert --no-commit rev1 rev2 I see a prepared commit message like Revert description from one commit This reverts commit SHA1 of one commit. The actual revert content is correct - it is all the relevant commits that were selected. I expect the message to reflect this: Revert description from commit1, description from commit2 This reverts commits SHA1 of commit1, SHA1 of commit2. Regards, ch3cooli -- 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: [BUG] gitweb: XSS vulnerability of RSS feed
On Tue, Nov 13, 2012 at 3:44 PM, Drew Northup n1xim.em...@gmail.com wrote:
On Mon, Nov 12, 2012 at 3:24 PM, Jeff King p...@peff.net wrote:
On Mon, Nov 12, 2012 at 01:55:46PM -0500, Drew Northup wrote:
+ # No XSS script/script inclusions
+ if ($input =~ m!(script)(.*)(/script)!){
+ return undef;
+ }
This is the wrong fix for a few reasons:
1. It is on the input-validation side, whereas the real problem is on
the output-quoting side. Your patch means I could not access a file
called scriptfoo/script. What we really want is to have the
unquoted name internally, but then make sure we quote it when
outputting as part of an HTML (or XML) file.
I don't buy the argument that we don't need to clean up the input as
well. There are scant few of us that are going to name a file
scriptalert(Something Awful)/script in this world (I am
probably one of them). Input validation is key to keeping problems
like this from coming up repeatedly as those writing the guts of
programs are typically more interested in getting the assigned task
done and reporting the output to the user in a safe manner.
Input cleanup or blacklisting *does not* prevent code injection (XSS
in this case). This is a myth.
Input validation has its place, and is done by gitweb when possible
(see e.g. evaluate_and_validate_params, validate_project, etc.).
But the proposed solution is not input validation.
'scriptalert(Something Awful)/script' is a perfectly valid filename.
As is more realistic create.uml or File Open screenshot.png.
And last and most important you have to escape output anyway;
filename is not HTML. Without escaping it would be rendered incorrectly.
And HTML escaping prevents XSS.
I think the right answer is going to be a well-placed call to esc_html.
This already happens automatically when we go through the CGI
element-building functions, but obviously we failed to make the call
when building the output manually. This is a great reason why template
languages which default to safe expansion should always be used.
Unfortunately, gitweb is living in 1995 in terms of web frameworks.
Escaping the output protects the user, but it DOES NOT protect the
server. We MUST handle both possibilities.
Errr, what?
If you are thinking about shell injection, we are covered.
Gitweb uses list form of open which is for shell what prepared
statements are for SQL. In one or two cases where we need to
use pipe we do shell escaping.
Besides, inserting one call to esc_html only fixes one attack path. I
didn't look to see if all others were already covered.
They should be covered. This case slipped.
--
Jakub Narebski
--
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
checkout from neighbour branch undeletes a path?
Hello. Am wondering if 'checkout branch path' undeletes the files? For the example below I'd like the 'file00.txt' to be deleted and never checked out from the previous branch... How can I do that? $ git init Initialized empty Git repository in /tmp/repo00/.git/ $ mkdir pathdir $ echo test00 pathdir/file00.txt $ git add pathdir $ git commit -am 'added file00.txt' [master (root-commit) d4f7c70] added file00.txt 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 pathdir/file00.txt $ git branch -m master branch00 $ git branch branch01 $ rm pathdir/file00.txt $ echo test01 pathdir/file01.txt $ git add pathdir $ git status $ git commit -am 'added file01.txt; removed file00.txt' [branch00 c3e78ff] added file01.txt; removed file00.txt 2 files changed, 1 insertions(+), 1 deletions(-) delete mode 100644 pathdir/file00.txt create mode 100644 pathdir/file01.txt $ git checkout branch01 Switched to branch 'branch01' $ rm -r pathdir $ git checkout branch00 pathdir $ find pathdir/ pathdir/ pathdir/file00.txt pathdir/file01.txt $ I know about 'merge' and it's not the what I need: to import only the particular subdirectory from the previous branch. Thank you. -- Peter Vereshagin pe...@vereshagin.org (http://vereshagin.org) pgp: A0E26627 -- 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] update-index/diff-index: use core.preloadindex to improve performance
Jeff King p...@peff.net wrote on 02.11.2012 16:26:16:
On Tue, Oct 30, 2012 at 10:50:42AM +0100, karsten.bl...@dcon.de wrote:
'update-index --refresh' and 'diff-index' (without --cached) don't
honor
the core.preloadindex setting yet. Porcelain commands using these
(such as
git [svn] rebase) suffer from this, especially on Windows.
Use read_cache_preload to improve performance.
Additionally, in builtin/diff.c, don't preload index status if we
don't
access the working copy (--cached).
Results with msysgit on WebKit repo (2GB in 200k files):
| update-index | diff-index | rebase
+--++-
msysgit-v1.8.0 | 9.157s |10.536s | 42.791s
+ preloadindex | 9.157s |10.536s | 28.725s
+ this patch| 2.329s | 2.752s | 15.152s
+ fscache [1] | 0.731s | 1.171s | 8.877s
Cool numbers. On my quad-core SSD Linux box, I saw a few speedups, too.
Here are the numbers for update-index --refresh on the WebKit repo
(all are wall clock time, best-of-five):
| before | after
---++
cold cache | 4.513s | 2.059s
warm cache | 0.252s | 0.164s
Great, and thanks for testing on Linux (I only have Linux VMs for testing,
and I couldn't get meaningful performance data from those).
Not as dramatic, but still nice. I wonder how a spinning disk would fare
on the cold-cache case, though. I also tried it with all but one CPU
disabled, and the warm cache case was a little bit slower.
Unfortunately, with a 'real' disk, cold cache times increase with the
number of threads. I've played around with '#define MAX_PARALLEL 20' in
preload-index.c, with the following results ('git update-index --refresh'
on WebKit repo, Win7 x64, Core i7 860 (2.8GHz 4 Core HT), WD VelociRaptor
(300G 10krpm 8ms), msysgit 1.8.0 + preload-index patch + fscache patch):
MAX_PARALLEL | cold cache | warm cache
-++
no preload | 49.938 | 9.204 (*)
1 | 45.412 | 1.622
2 | 55.334 | 1.123
3 | 65.973 | 0.982
4 | 67.579 | 0.889
5 | 76.159 | 0.827
6 | 81.510 | 0.811
7 | 86.269 | 0.858
8 | 85.862 | 0.827
...
10 | 87.953 | 0.717
...
20 |176.251 | 0.749
(*) core.preloadindex currently also disables fscache, thus the 9s
With more threads, Windows resource monitor also shows increasing disk
queue length and response times.
It seems clear that more concurrent disk seeks hurt cold cache performance
pretty badly. On the other hand, warm cache improvements for #threads
#cores are only about 10 - 20%.
I don't know if Linux is better at caching / prefetching directory
listings (might depend on file system, too), but perhaps MAX_PARALLEL
should be set to a more reasonable value, or be made configurable (e.g.
core.preloadIndexThreads)?
Karsten
--
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] update-index/diff-index: use core.preloadindex to improve performance
Jeff King p...@peff.net wrote on 02.11.2012 16:38:00: On Fri, Nov 02, 2012 at 11:26:16AM -0400, Jeff King wrote: Still, I don't think we need to worry about performance regressions, because people who don't have a setup suitable for it will not turn on core.preloadindex in the first place. And if they have it on, the more places we use it, probably the better. BTW, your patch was badly damaged in transit (wrapped, and tabs converted to spaces). I was able to fix it up, but please check your mailer's settings. Yes, I feared as much, that's why I included the pull URL (the company MTA only accepts outbound mail from Notes clients, sorry). Is there a policy for people with broken mailers (send patch as attachment, add pull URL more prominently, don't include plaintext patch at all...)? -- 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 v4 0/4] Introduce diff.submodule
v1 is here: http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com v2 is here: http://mid.gmane.org/1351766630-4837-1-git-send-email-artag...@gmail.com v3 is here: http://mid.gmane.org/1352653146-3932-1-git-send-email-artag...@gmail.com This version was prepared in response to Peff's review of v3. What changed: * Functional code simplified and moved to git_diff_ui_config. * Peff contributed one additional patch to the series. Thanks. Ram Jeff King (1): diff: rename set variable Ramkumar Ramachandra (3): Documentation: move diff.wordRegex from config.txt to diff-config.txt diff: introduce diff.submodule configuration variable submodule: display summary header in bold Documentation/config.txt |6 - Documentation/diff-config.txt| 13 ++ Documentation/diff-options.txt |3 +- diff.c | 46 - submodule.c |8 +++--- submodule.h |2 +- t/t4041-diff-submodule-option.sh | 30 - 7 files changed, 84 insertions(+), 24 deletions(-) -- 1.7.8.1.362.g5d6df.dirty -- 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 v4 1/4] Documentation: move diff.wordRegex from config.txt to diff-config.txt
19299a8 (Documentation: Move diff.driver.* from config.txt to diff-config.txt, 2011-04-07) moved the diff configuration options to diff-config.txt, but forgot about diff.wordRegex, which was left behind in config.txt. Fix this. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Documentation/config.txt |6 -- Documentation/diff-config.txt |6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 9a0544c..e70216d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -962,12 +962,6 @@ difftool.tool.cmd:: difftool.prompt:: Prompt before each invocation of the diff tool. -diff.wordRegex:: - A POSIX Extended Regular Expression used to determine what is a word - when performing word-by-word difference calculations. Character - sequences that match the regular expression are words, all other - characters are *ignorable* whitespace. - fetch.recurseSubmodules:: This option can be either set to a boolean value or to 'on-demand'. Setting it to a boolean changes the behavior of fetch and pull to diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt index 75ab8a5..decd370 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -107,6 +107,12 @@ diff.suppressBlankEmpty:: A boolean to inhibit the standard behavior of printing a space before each empty output line. Defaults to false. +diff.wordRegex:: + A POSIX Extended Regular Expression used to determine what is a word + when performing word-by-word difference calculations. Character + sequences that match the regular expression are words, all other + characters are *ignorable* whitespace. + diff.driver.command:: The custom diff driver command. See linkgit:gitattributes[5] for details. -- 1.7.8.1.362.g5d6df.dirty -- 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 v4 2/4] diff: introduce diff.submodule configuration variable
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/diff-config.txt|7 +++
Documentation/diff-options.txt |3 ++-
diff.c | 32
t/t4041-diff-submodule-option.sh | 30 +-
4 files changed, 66 insertions(+), 6 deletions(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index decd370..89dd634 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -107,6 +107,13 @@ diff.suppressBlankEmpty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
+diff.submodule::
+ Specify the format in which differences in submodules are
+ shown. The log format lists the commits in the range like
+ linkgit:git-submodule[1] `summary` does. The short format
+ format just shows the names of the commits at the beginning
+ and end of the range. Defaults to short.
+
diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a word
when performing word-by-word difference calculations. Character
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index cf4b216..f4f7e25 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -170,7 +170,8 @@ any of those replacements occurred.
the commits in the range like linkgit:git-submodule[1] `summary` does.
Omitting the `--submodule` option or specifying `--submodule=short`,
uses the 'short' format. This format just shows the names of the commits
- at the beginning and end of the range.
+ at the beginning and end of the range. Can be tweaked via the
+ `diff.submodule` configuration variable.
--color[=when]::
Show colored diff.
diff --git a/diff.c b/diff.c
index e89a201..7f2a255 100644
--- a/diff.c
+++ b/diff.c
@@ -123,6 +123,17 @@ static int parse_dirstat_params(struct diff_options
*options, const char *params
return ret;
}
+static int parse_submodule_params(struct diff_options *options, const char
*value)
+{
+ if (!strcmp(value, log))
+ DIFF_OPT_SET(options, SUBMODULE_LOG);
+ else if (!strcmp(value, short))
+ DIFF_OPT_CLR(options, SUBMODULE_LOG);
+ else
+ return -1;
+ return 0;
+}
+
static int git_config_rename(const char *var, const char *value)
{
if (!value)
@@ -178,6 +189,13 @@ int git_diff_ui_config(const char *var, const char *value,
void *cb)
if (!strcmp(var, diff.ignoresubmodules))
handle_ignore_submodules_arg(default_diff_options, value);
+ if (!strcmp(var, diff.submodule)) {
+ if (parse_submodule_params(default_diff_options, value))
+ warning(_(Unknown value for 'diff.submodule' config
variable: '%s'),
+ value);
+ return 0;
+ }
+
if (git_color_config(var, value, cb) 0)
return -1;
@@ -3475,6 +3493,14 @@ static int parse_dirstat_opt(struct diff_options
*options, const char *params)
return 1;
}
+static int parse_submodule_opt(struct diff_options *options, const char *value)
+{
+ if (parse_submodule_params(options, value))
+ die(_(Failed to parse --submodule option parameter: '%s'),
+ value);
+ return 1;
+}
+
int diff_opt_parse(struct diff_options *options, const char **av, int ac)
{
const char *arg = av[0];
@@ -3655,10 +3681,8 @@ int diff_opt_parse(struct diff_options *options, const
char **av, int ac)
handle_ignore_submodules_arg(options, arg + 20);
} else if (!strcmp(arg, --submodule))
DIFF_OPT_SET(options, SUBMODULE_LOG);
- else if (!prefixcmp(arg, --submodule=)) {
- if (!strcmp(arg + 12, log))
- DIFF_OPT_SET(options, SUBMODULE_LOG);
- }
+ else if (!prefixcmp(arg, --submodule=))
+ return parse_submodule_opt(options, arg + 12);
/* misc options */
else if (!strcmp(arg, -z))
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 6c01d0c..e401814 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -33,6 +33,7 @@ test_create_repo sm1
add_file . foo /dev/null
head1=$(add_file sm1 foo1 foo2)
+fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
test_expect_success 'added submodule'
git add sm1
@@ -43,6 +44,34 @@ EOF
test_cmp expected actual
+test_expect_success 'added submodule, set diff.submodule'
+ git config diff.submodule log
+ git add sm1
+ git diff --cached actual
+ cat expected -EOF
[PATCH v4 3/4] diff: rename set variable
From: Jeff King p...@peff.net
Once upon a time the builtin_diff function used one color, and the color
variables were called set and reset. Nowadays it is a much longer
function and we use several colors (e.g., add, del). Rename set to
meta to show that it is the color for showing diff meta-info (it still
does not indicate that it is a color, but at least it matches the
scheme of the other color variables).
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
diff.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index 7f2a255..ffaed72 100644
--- a/diff.c
+++ b/diff.c
@@ -2240,7 +2240,7 @@ static void builtin_diff(const char *name_a,
mmfile_t mf1, mf2;
const char *lbl[2];
char *a_one, *b_two;
- const char *set = diff_get_color_opt(o, DIFF_METAINFO);
+ const char *meta = diff_get_color_opt(o, DIFF_METAINFO);
const char *reset = diff_get_color_opt(o, DIFF_RESET);
const char *a_prefix, *b_prefix;
struct userdiff_driver *textconv_one = NULL;
@@ -2287,24 +2287,24 @@ static void builtin_diff(const char *name_a,
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
lbl[0] = DIFF_FILE_VALID(one) ? a_one : /dev/null;
lbl[1] = DIFF_FILE_VALID(two) ? b_two : /dev/null;
- strbuf_addf(header, %s%sdiff --git %s %s%s\n, line_prefix, set,
a_one, b_two, reset);
+ strbuf_addf(header, %s%sdiff --git %s %s%s\n, line_prefix, meta,
a_one, b_two, reset);
if (lbl[0][0] == '/') {
/* /dev/null */
- strbuf_addf(header, %s%snew file mode %06o%s\n, line_prefix,
set, two-mode, reset);
+ strbuf_addf(header, %s%snew file mode %06o%s\n, line_prefix,
meta, two-mode, reset);
if (xfrm_msg)
strbuf_addstr(header, xfrm_msg);
must_show_header = 1;
}
else if (lbl[1][0] == '/') {
- strbuf_addf(header, %s%sdeleted file mode %06o%s\n,
line_prefix, set, one-mode, reset);
+ strbuf_addf(header, %s%sdeleted file mode %06o%s\n,
line_prefix, meta, one-mode, reset);
if (xfrm_msg)
strbuf_addstr(header, xfrm_msg);
must_show_header = 1;
}
else {
if (one-mode != two-mode) {
- strbuf_addf(header, %s%sold mode %06o%s\n,
line_prefix, set, one-mode, reset);
- strbuf_addf(header, %s%snew mode %06o%s\n,
line_prefix, set, two-mode, reset);
+ strbuf_addf(header, %s%sold mode %06o%s\n,
line_prefix, meta, one-mode, reset);
+ strbuf_addf(header, %s%snew mode %06o%s\n,
line_prefix, meta, two-mode, reset);
must_show_header = 1;
}
if (xfrm_msg)
--
1.7.8.1.362.g5d6df.dirty
--
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 v4 4/4] submodule: display summary header in bold
Currently, 'git diff --submodule' displays output with a bold diff
header for non-submodules. So this part is in bold:
diff --git a/file1 b/file1
index 30b2f6c..2638038 100644
--- a/file1
+++ b/file1
For submodules, the header looks like this:
Submodule submodule1 012b072..248d0fd:
Unfortunately, it's easy to miss in the output because it's not bold.
Change this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
diff.c |2 +-
submodule.c |8
submodule.h |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index ffaed72..1065978 100644
--- a/diff.c
+++ b/diff.c
@@ -2261,7 +2261,7 @@ static void builtin_diff(const char *name_a,
const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
show_submodule_summary(o-file, one ? one-path : two-path,
one-sha1, two-sha1, two-dirty_submodule,
- del, add, reset);
+ meta, del, add, reset);
return;
}
diff --git a/submodule.c b/submodule.c
index e3e0b45..2f55436 100644
--- a/submodule.c
+++ b/submodule.c
@@ -258,7 +258,7 @@ int parse_fetch_recurse_submodules_arg(const char *opt,
const char *arg)
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
- unsigned dirty_submodule,
+ unsigned dirty_submodule, const char *meta,
const char *del, const char *add, const char *reset)
{
struct rev_info rev;
@@ -292,15 +292,15 @@ void show_submodule_summary(FILE *f, const char *path,
return;
}
- strbuf_addf(sb, Submodule %s %s.., path,
+ strbuf_addf(sb, %sSubmodule %s %s.., meta, path,
find_unique_abbrev(one, DEFAULT_ABBREV));
if (!fast_backward !fast_forward)
strbuf_addch(sb, '.');
strbuf_addf(sb, %s, find_unique_abbrev(two, DEFAULT_ABBREV));
if (message)
- strbuf_addf(sb, %s\n, message);
+ strbuf_addf(sb, %s%s\n, message, reset);
else
- strbuf_addf(sb, %s:\n, fast_backward ? (rewind) : );
+ strbuf_addf(sb, %s:%s\n, fast_backward ? (rewind) : ,
reset);
fwrite(sb.buf, sb.len, 1, f);
if (!message) {
diff --git a/submodule.h b/submodule.h
index f2e8271..3dc1b3f 100644
--- a/submodule.h
+++ b/submodule.h
@@ -20,7 +20,7 @@ void handle_ignore_submodules_arg(struct diff_options
*diffopt, const char *);
int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
- unsigned dirty_submodule,
+ unsigned dirty_submodule, const char *meta,
const char *del, const char *add, const char *reset);
void set_config_fetch_recurse_submodules(int value);
void check_for_new_submodule_commits(unsigned char new_sha1[20]);
--
1.7.8.1.362.g5d6df.dirty
--
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/3] diff: introduce diff.submodule configuration variable
Jeff King wrote:
On Sun, Nov 11, 2012 at 10:29:05PM +0530, Ramkumar Ramachandra wrote:
@@ -223,6 +238,15 @@ int git_diff_basic_config(const char *var, const char
*value, void *cb)
return 0;
}
+ if (!strcmp(var, diff.submodule)) {
Shouldn't this be in git_diff_ui_config so it does not affect scripts
calling plumbing?
I honestly didn't understand the difference between
git_diff_basic_config and git_diff_ui_config. The latter function
calls the former function at the end of its body. Why are they two
separate functions in the first place?
Btw, I just posted a follow-up.
Ram
--
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: [BUG] gitweb: XSS vulnerability of RSS feed
The problem with input filtering is that you can only filter for one output scenario. What if the the input is going to be output in a wiki like environment, or to pdf, or whatever? Then you have to unescape the data again, and maybe apply filtering/escaping for those environments. You only know how to escape data when you are going to output it, so then is the the best moment to escape it. -- 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: [BUG] gitweb: XSS vulnerability of RSS feed
On Tue, Nov 13, 2012 at 4:45 PM, Kevin i...@ikke.info wrote: The problem with input filtering is that you can only filter for one output scenario. What if the the input is going to be output in a wiki like environment, or to pdf, or whatever? Then you have to unescape the data again, and maybe apply filtering/escaping for those environments. You only know how to escape data when you are going to output it, so then is the the best moment to escape it. Also there are so many ways to evade XSS filtering https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet If you can and should escape data (like in our case), it cannot not work; not possible to evade it. -- Jakub Narebski -- 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] send-email: add proper default sender
Jeff King p...@peff.net writes: On Tue, Nov 13, 2012 at 07:42:58AM +0100, Felipe Contreras wrote: ... 5) GIT_COMMITTER Who should the emails appear to be from? [Felipe Contreras 2nd felipe.contrera...@gmail.com] Whoa, what happened there? Well: $sender = $repoauthor || $repocommitter || ''; ($repoauthor) = Git::ident_person(@repo, 'author'); % ./git var GIT_AUTHOR_IDENT Felipe Contreras 2nd felipe.contrera...@gmail.com 1352783223 +0100 That's right, AUTHOR_IDENT would fall back to the default email and full name. Yeah, I find that somewhat questionable in the current behavior, and I'd consider it a bug. Typically we prefer the committer ident when given a choice (e.g., for writing reflog entries). Just to make sure I follow the discussion correctly, do you mean that the bug is that we pick a fuzzy AUTHOR when COMMITTER is specified more concretely and we usually use COMMIITTER for this kind of thing in the first place but send-email does not in this case (I do not see git var GIT_AUTHOR_IDENT returning value from the implicit logic as a bug in this case---just making sure). 6.1) GIT_AUTHOR without anything else fatal: empty ident name (for felipec@nysa.(none)) not allowed var GIT_COMMITTER_IDENT: command returned error: 128 Doesn't that seem like a regression? It used to work. I do not think we mind a change to favor GIT_COMMITTER setting over GIT_AUTHOR to be consistent with others too much, but that indeed is a big change. People who are used to the inconsistency that send-email favors AUTHOR over COMMITTER will certainly find it as a regression. The explicitness needs to be tied to the specific ident we grabbed. Probably adding a git var GIT_AUTHOR_EXPLICIT would be enough, or alternatively, adding a flag to git var to error out rather than return a non-explicit ident (this may need to adjust the error handling of the git var calls from send-email). Yeah, something like that would be necessary for git var users to make this kind of decision. While simultaneously breaking git commit for people who are happily using the implicit generation. I can see the appeal of doing so; I was tempted to suggest it when I cleaned up IDENT_STRICT a few months back. But do we have any data on how many people are currently using that feature that would be annoyed by it? As we didn't break git commit when you worked on IDENT_STRICT, I do not think we have any data on it ;-) ... It may be something I would work on myself in the future, but I have other things to work on at the moment, and since you are interested in the topic, I thought you would be a good candidate to polish it enough to be suitable upstream. But instead I see a lot of push-back on what I considered to be a fairly straightforward technical comment on a regression. ... But I feel like I am fighting an uphill battle just to convince you that regressions are bad, and that I am having to make the same points repeatedly. That makes me frustrated and less excited about reviewing your patches; and when I say it is not my itch, that is my most polite way of saying If that is going to be your attitude, then I do not feel like dealing with you anymore on this topic. For a change with low benefit/cost ratio like this, the best course of action often is to stop paying attention to the thread that has become unproductive and venomous, and resurrect the topic after people forgot about it and doing it right yourself ;-). -- 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/3] diff: introduce diff.submodule configuration variable
Ramkumar Ramachandra artag...@gmail.com writes:
Jeff King wrote:
On Sun, Nov 11, 2012 at 10:29:05PM +0530, Ramkumar Ramachandra wrote:
@@ -223,6 +238,15 @@ int git_diff_basic_config(const char *var, const char
*value, void *cb)
return 0;
}
+ if (!strcmp(var, diff.submodule)) {
Shouldn't this be in git_diff_ui_config so it does not affect scripts
calling plumbing?
I honestly didn't understand the difference between
git_diff_basic_config and git_diff_ui_config. The latter function
calls the former function at the end of its body. Why are they two
separate functions in the first place?
In case you meant s/didn't/don't/, git_diff_ui_config() should be
called only by human-facing Porcelain commands where their
behaviours can and should be affected by end user configuration
variables.
When a configuration variable should not affect output from plumbing
commands like diff-files, diff-index, and diff-tree, it must not be
read in git_diff_basic_config(), but in git_diff_ui_config().
The output from git format-patch is consumed by git apply that
expects Subproject commit %s\n with fully spelled object name, so
your configuration must not affect the output of format-patch,
either.
--
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: Notes in format-patch
Michael J Gruber g...@drmicha.warpmail.net writes: Michael J Gruber venit, vidit, dixit 12.11.2012 15:18: 'git replace' parses the revision arguments when it creates replacements (so that a sha1 can be abbreviated, e.g.) but not when deleting replacements. Make it parse the argument to 'replace -d' in the same way. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: v3 safeguards the hex buffer against reuse builtin/replace.c | 16 ++-- t/t6050-replace.sh | 11 +++ 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/builtin/replace.c b/builtin/replace.c By the way - Junio, is that the intented outcome of format-patch --notes? I would rather put the newline between the note and the diffstat... I do not mind (actually I personally would prefer to see) a blank line between the three-dash and Notes:, but I agree that we should have a blank line before the diffstat block. -- 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: Commit message problem of reverting multiple commits
乙酸鋰 ch3co...@gmail.com writes: I ran git 1.8.0 command line git revert --no-commit rev1 rev2 I see a prepared commit message like Revert description from one commit This reverts commit SHA1 of one commit. The actual revert content is correct - it is all the relevant commits that were selected. I expect the message to reflect this: Revert description from commit1, description from commit2 This reverts commits SHA1 of commit1, SHA1 of commit2. Hrmph. I actually think the revert-content is not correct. I think the command should not take more than one commit on the command line when --no-commit is in use in the first place (the same thing can be said for cherry-pick). After all, git revert rev1 rev2 is to revert rev1 and then rev2 independently, so unless that option is spelled --squash, the resulting history should have two commits that reverts rev1 and rev2 independently. -- 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: checkout from neighbour branch undeletes a path?
Peter Vereshagin pe...@vereshagin.org writes: Am wondering if 'checkout branch path' undeletes the files? git checkout branch path (by the way, branch does not have to be a branch name; any commit object name would do, like git checkout HEAD^^ hello.c) is a way to check out named path(s) out of the named commit. If the commit branch has path in it, its contents are checked out to path in your current working tree (and the entry in the index updated to match it). If you happen to have removed path in your current working tree before running that command, it might look as if there is some undelete going on, but that is a wrong way to look at things. The version of path in the branch may or may not be similar to what you have removed earlier. -- 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] update-index/diff-index: use core.preloadindex to improve performance
karsten.bl...@dcon.de writes: Jeff King p...@peff.net wrote on 02.11.2012 16:38:00: On Fri, Nov 02, 2012 at 11:26:16AM -0400, Jeff King wrote: Still, I don't think we need to worry about performance regressions, because people who don't have a setup suitable for it will not turn on core.preloadindex in the first place. And if they have it on, the more places we use it, probably the better. BTW, your patch was badly damaged in transit (wrapped, and tabs converted to spaces). I was able to fix it up, but please check your mailer's settings. Yes, I feared as much, that's why I included the pull URL (the company MTA only accepts outbound mail from Notes clients, sorry). Is there a policy for people with broken mailers (send patch as attachment, add pull URL more prominently, don't include plaintext patch at all...)? If anything, fix your mailer probably is the policy you are looking for, I think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] send-email: add proper default sender
On Tue, Nov 13, 2012 at 10:06:26AM +0100, Felipe Contreras wrote: Those people would also not be using a new version of git-send-email, and it will always prompt. I thought we were talking about what send-email should do in future versions. Namely, loosening that safety valve (the prompt) because it is inconvenient, but tightening the checks so that losing the safety valve is not a problem. Yeah, but all I'm saying is that the issue happens, you seemed to suggest that it doesn't. What is it? If it is bad guesses like user@host.(none) on unconfigured systems, then I did not suggest it doesn't happen. I said that it happened with older versions of git, but that it has now been fixed. Of course it will continue to happen for people on older versions of git until they upgrade. I cannot go back in time and fix released versions. If it is guessing at all to end up with user@host.domain for a host that does not receive mail, yes, that happens, and I have been very clear that it does. The safety valve is showing the ident and a warning to the user during the commit process. I do not see any point in discussing the former when considering future changes to git. It is already disallowed by current versions of git, and we are just waiting for the whole world to upgrade to a fixed version. I can see the argument for tightening the check to disallow the latter. But it would also hurt real people who are relying on the feature. Perhaps it would make sense to adopt the implicit_ident_advice in other code paths besides git commit (e.g., via git var). I think you are the one that is not understanding what I'm saying. But I don't think it matters. This is what I'm saying; the current situation with 'git commit' is not OK, _both_ 'git commit' and 'git send-email' should change. Perhaps I am being dense, but this is the first time it became apparent to me that you are arguing for a change in git commit. Indeed I would, but there's other people that would benefit from this patch. I'm sure I'm not the only person that doesn't have sendmail.from configured, but does have user.name/user.email, and is constantly typing enter. And the difference is that I'm _real_, the hypothetical user that sends patches with GIT_AUTHOR_NAME/EMAIL is not. I would be convinced otherwise if some evidence was presented that such a user is real though. Sadly we cannot poll the configuration of every user, nor expect them all to pay attention to this discussion on the list. So we cannot take the absence of comment from such users as evidence that they do not exist. Instead we must use our judgement about what is being changed, and we tend to err on the side of keeping the status quo, since that is what the silent majority is busy _not_ complaining about. We use the same judgement on the other side, too. Right now your evidence is 1 user wants this, 0 users do not. But we can guess that there are other people who would like the intent of your patch, but did not care enough or are not active enough on the list to write the patch themselves or comment on this thread. It is also very easy to me accept the status quo when it is not in fundamental conflict with the proposed improvement, but simply a matter of implementation (which it is the case for send-email stopping prompting in some cases, though it is not for changing the behavior of git-commit). And to balance you need to *measure*, and that means taking into consideration who actually uses the features, if there's any. And it looks to me this is a feature nobody uses. You said measure and then it looks to me like. What did you measure? Did you consider systematic bias in your measurement, like the fact that people who are using the feature have no reason to come on the list and announce it? But listen closely to what you said: I actually think it would make more sense to drop the prompt entirely and just die when the user has not given us a usable ident. Suppose somebody has a full name, and a fully qualified domain name, and he can receive mails to it directly. Such a user would not need a git configuration, and would not need $EMAIL, or anything. Currently 'git send-email' will throw 'Felipe Contreras feli...@felipec.org' which would actually work, but is not explicit. You are suggesting to break that use-case. You are introducing a regression. And this case is realistic, unlike the GIT_AUTHOR_NAME/EMAIL. Isn't it? Yes, dying would be a regression, in that you would have to configure your name via the environment and re-run rather than type it at the prompt. You raise a good point that for people who _could_ take the implicit default, hitting enter is working fine now, and we would lose that. I'd be fine with also just continuing to prompt in the implicit case. But that is a much smaller issue to me than having send-email fail to respect environment variables and silently use user.*, which is what started this whole
[PATCH 1/6] ident: make user_ident_explicitly_given private
There are no users of this global variable, as queriers
go through the user_ident_sufficiently_given accessor.
Let's make it private, which will enable further
refactoring.
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 4
ident.c | 6 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index dbd8018..50d9eea 100644
--- a/cache.h
+++ b/cache.h
@@ -1149,10 +1149,6 @@ struct config_include_data {
#define CONFIG_INCLUDE_INIT { 0 }
extern int git_config_include(const char *name, const char *value, void *data);
-#define IDENT_NAME_GIVEN 01
-#define IDENT_MAIL_GIVEN 02
-#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
-extern int user_ident_explicitly_given;
extern int user_ident_sufficiently_given(void);
extern const char *git_commit_encoding;
diff --git a/ident.c b/ident.c
index a4bf206..733d69d 100644
--- a/ident.c
+++ b/ident.c
@@ -10,7 +10,11 @@
static struct strbuf git_default_name = STRBUF_INIT;
static struct strbuf git_default_email = STRBUF_INIT;
static char git_default_date[50];
-int user_ident_explicitly_given;
+
+#define IDENT_NAME_GIVEN 01
+#define IDENT_MAIL_GIVEN 02
+#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
+static int user_ident_explicitly_given;
#ifdef NO_GECOS_IN_PWENT
#define get_gecos(ignored)
--
1.8.0.207.gdf2154c
--
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/6] ident: keep separate explicit flags for author and committer
We keep track of whether the user ident was given to us
explicitly, or if we guessed at it from system parameters
like username and hostname. However, we kept only a single
variable. This covers the common cases (because the author
and committer will usually come from the same explicit
source), but can miss two cases:
1. GIT_COMMITTER_* is set explicitly, but we fallback for
GIT_AUTHOR. We claim the ident is explicit, even though
the author is not.
2. GIT_AUTHOR_* is set and we ask for author ident, but
not committer ident. We will claim the ident is
implicit, even though it is explicit.
This patch uses two variables instead of one, updates both
when we set the fallback values, and updates them
individually when we read from the environment.
Rather than keep user_ident_sufficiently_given as a
compatibility wrapper, we update the only two callers to
check the committer_ident, which matches their intent and
what was happening already.
Signed-off-by: Jeff King p...@peff.net
---
Case 1 made me initially think might need to check
author_ident_sufficiently_given when deciding whether to show the
Author: line during commit. But I don't think it is necessary, as we
already check !strcmp(author, committer); if the committer is explicit
and the author is identical, even if it is implicit, there is no point
in telling the user.
builtin/commit.c | 4 ++--
cache.h | 3 ++-
ident.c | 32 +---
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..d6dd3df 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -755,7 +755,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
ident_shown++ ? : \n,
author_ident-buf);
- if (!user_ident_sufficiently_given())
+ if (!committer_ident_sufficiently_given())
status_printf_ln(s, GIT_COLOR_NORMAL,
_(%s
Committer: %s),
@@ -1265,7 +1265,7 @@ static void print_summary(const char *prefix, const
unsigned char *sha1,
strbuf_addstr(format, \n Author: );
strbuf_addbuf_percentquote(format, author_ident);
}
- if (!user_ident_sufficiently_given()) {
+ if (!committer_ident_sufficiently_given()) {
strbuf_addstr(format, \n Committer: );
strbuf_addbuf_percentquote(format, committer_ident);
if (advice_implicit_identity) {
diff --git a/cache.h b/cache.h
index 50d9eea..18fdd18 100644
--- a/cache.h
+++ b/cache.h
@@ -1149,7 +1149,8 @@ struct config_include_data {
#define CONFIG_INCLUDE_INIT { 0 }
extern int git_config_include(const char *name, const char *value, void *data);
-extern int user_ident_sufficiently_given(void);
+extern int committer_ident_sufficiently_given(void);
+extern int author_ident_sufficiently_given(void);
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
diff --git a/ident.c b/ident.c
index 733d69d..ac9672f 100644
--- a/ident.c
+++ b/ident.c
@@ -14,7 +14,8 @@ static char git_default_date[50];
#define IDENT_NAME_GIVEN 01
#define IDENT_MAIL_GIVEN 02
#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
-static int user_ident_explicitly_given;
+static int committer_ident_explicitly_given;
+static int author_ident_explicitly_given;
#ifdef NO_GECOS_IN_PWENT
#define get_gecos(ignored)
@@ -113,7 +114,8 @@ const char *ident_default_email(void)
if (email email[0]) {
strbuf_addstr(git_default_email, email);
- user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ committer_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ author_ident_explicitly_given |= IDENT_MAIL_GIVEN;
} else
copy_email(xgetpwuid_self(), git_default_email);
strbuf_trim(git_default_email);
@@ -331,6 +333,10 @@ const char *fmt_name(const char *name, const char *email)
const char *git_author_info(int flag)
{
+ if (getenv(GIT_AUTHOR_NAME))
+ author_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ if (getenv(GIT_AUTHOR_EMAIL))
+ author_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return fmt_ident(getenv(GIT_AUTHOR_NAME),
getenv(GIT_AUTHOR_EMAIL),
getenv(GIT_AUTHOR_DATE),
@@ -340,16 +346,16 @@ const char *git_author_info(int flag)
const char *git_committer_info(int flag)
{
if (getenv(GIT_COMMITTER_NAME))
- user_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ committer_ident_explicitly_given |= IDENT_NAME_GIVEN;
if (getenv(GIT_COMMITTER_EMAIL))
- user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+
[PATCH 3/6] var: accept multiple variables on the command line
Git-var currently only accepts a single value to print. This
is inefficient if the caller is interested in finding
multiple values, as they must invoke git-var multiple times.
This patch lets callers specify multiple variables, and
prints one per line.
Signed-off-by: Jeff King p...@peff.net
---
This will later let us get the explicit flag for free.
Documentation/git-var.txt | 9 +++--
builtin/var.c | 13 +++--
t/t0007-git-var.sh| 29 +
3 files changed, 43 insertions(+), 8 deletions(-)
create mode 100755 t/t0007-git-var.sh
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index 67edf58..53abba5 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -9,11 +9,16 @@ git-var - Show a git logical variable
SYNOPSIS
[verse]
-'git var' ( -l | variable )
+'git var' ( -l | variable... )
DESCRIPTION
---
-Prints a git logical variable.
+Prints one or more git logical variables, separated by newlines.
+
+Note that some variables may contain newlines themselves (e.g.,
+`GIT_EDITOR`), and it is therefore possible to receive ambiguous output
+when requesting multiple variables. This can be mitigated by putting any
+such variables at the end of the list.
OPTIONS
---
diff --git a/builtin/var.c b/builtin/var.c
index aedbb53..49b48f5 100644
--- a/builtin/var.c
+++ b/builtin/var.c
@@ -73,8 +73,7 @@ static int show_config(const char *var, const char *value,
void *cb)
int cmd_var(int argc, const char **argv, const char *prefix)
{
- const char *val = NULL;
- if (argc != 2)
+ if (argc 2)
usage(var_usage);
if (strcmp(argv[1], -l) == 0) {
@@ -83,11 +82,13 @@ int cmd_var(int argc, const char **argv, const char *prefix)
return 0;
}
git_config(git_default_config, NULL);
- val = read_var(argv[1]);
- if (!val)
- usage(var_usage);
- printf(%s\n, val);
+ while (*++argv) {
+ const char *val = read_var(*argv);
+ if (!val)
+ usage(var_usage);
+ printf(%s\n, val);
+ }
return 0;
}
diff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh
new file mode 100755
index 000..45a5f66
--- /dev/null
+++ b/t/t0007-git-var.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+test_description='basic sanity checks for git var'
+. ./test-lib.sh
+
+test_expect_success 'get GIT_AUTHOR_IDENT' '
+ test_tick
+ echo A U Thor aut...@example.com 1112911993 -0700 expect
+ git var GIT_AUTHOR_IDENT actual
+ test_cmp expect actual
+'
+
+test_expect_success 'get GIT_COMMITTER_IDENT' '
+ test_tick
+ echo C O Mitter commit...@example.com 1112912053 -0700 expect
+ git var GIT_COMMITTER_IDENT actual
+ test_cmp expect actual
+'
+
+test_expect_success 'git var can show multiple values' '
+ cat expect -\EOF
+ A U Thor aut...@example.com 1112912053 -0700
+ C O Mitter commit...@example.com 1112912053 -0700
+ EOF
+ git var GIT_AUTHOR_IDENT GIT_COMMITTER_IDENT actual
+ test_cmp expect actual
+'
+
+test_done
--
1.8.0.207.gdf2154c
--
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 4/6] var: provide explicit/implicit ident information
Internally, we keep track of whether the author or committer
ident information was provided by the user, or whether it
was implicitly determined by the system. However, there is
currently no way for external programs or scripts to get
this information without re-implementing the ident logic
themselves. Let's provide a way for them to do so.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/git-var.txt | 8
builtin/var.c | 27 +++
t/t0007-git-var.sh| 36
3 files changed, 71 insertions(+)
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index 53abba5..963b8d4 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -39,9 +39,17 @@ VARIABLES
GIT_AUTHOR_IDENT::
The author of a piece of code.
+GIT_AUTHOR_EXPLICIT::
+Outputs 1 if the author identity was provided explicitly by the
+user (in the config or environment), or 0 if it was determined
+implicitly from the system.
+
GIT_COMMITTER_IDENT::
The person who put a piece of code into git.
+GIT_COMMITTER_EXPLICIT::
+Like GIT_AUTHOR_EXPLICIT, but for the committer ident.
+
GIT_EDITOR::
Text editor for use by git commands. The value is meant to be
interpreted by the shell when it is used. Examples: `~/bin/vi`,
diff --git a/builtin/var.c b/builtin/var.c
index 49b48f5..ce28101 100644
--- a/builtin/var.c
+++ b/builtin/var.c
@@ -26,13 +26,40 @@ static const char *pager(int flag)
return pgm;
}
+static const char *explicit_ident(const char * (*get_ident)(int),
+ int (*check_ident)(void))
+{
+ /*
+* Prime the explicit flag by getting the identity.
+* We do not want to be strict here, because we would not want
+* to die on bogus implicit values, but instead just report that they
+* are not explicit.
+*/
+ get_ident(0);
+ return check_ident() ? 1 : 0;
+}
+
+static const char *committer_explicit(int flag)
+{
+ return explicit_ident(git_committer_info,
+ committer_ident_sufficiently_given);
+}
+
+static const char *author_explicit(int flag)
+{
+ return explicit_ident(git_author_info,
+ author_ident_sufficiently_given);
+}
+
struct git_var {
const char *name;
const char *(*read)(int);
};
static struct git_var git_vars[] = {
{ GIT_COMMITTER_IDENT, git_committer_info },
+ { GIT_COMMITTER_EXPLICIT, committer_explicit },
{ GIT_AUTHOR_IDENT, git_author_info },
+ { GIT_AUTHOR_EXPLICIT, author_explicit },
{ GIT_EDITOR, editor },
{ GIT_PAGER, pager },
{ , NULL },
diff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh
index 45a5f66..66b9810 100755
--- a/t/t0007-git-var.sh
+++ b/t/t0007-git-var.sh
@@ -26,4 +26,40 @@ test_expect_success 'git var can show multiple values' '
test_cmp expect actual
'
+for type in AUTHOR COMMITTER; do
+ test_expect_success $type ident can detect implicit values
+ echo 0 expect
+ (
+ sane_unset GIT_${type}_NAME
+ sane_unset GIT_${type}_EMAIL
+ sane_unset EMAIL
+ git var GIT_${type}_EXPLICIT actual
+ )
+ test_cmp expect actual
+
+
+ test_expect_success $type ident is explicit via environment
+ echo 1 expect
+ (
+ GIT_${type}_NAME='A Name'
+ export GIT_${type}_NAME
+ GIT_${type}_EMAIL='n...@example.com'
+ export GIT_${type}_EMAIL
+ git var GIT_${type}_EXPLICIT actual
+ )
+ test_cmp expect actual
+
+
+ test_expect_success $type ident is explicit via config
+ echo 1 expect
+ test_config user.name 'A Name'
+ test_config user.email 'n...@example.com'
+ (
+ sane_unset GIT_${type}_NAME
+ sane_unset GIT_${type}_EMAIL
+ git var GIT_${type}_EXPLICIT actual
+ )
+
+done
+
test_done
--
1.8.0.207.gdf2154c
--
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 5/6] Git.pm: teach ident to query explicitness
git var recently learned to report on whether an ident we
fetch from it was configured explicitly or implicitly. Let's
make that information available to callers of the ident
function.
Because evaluating ident in an array versus scalar context
already has a meaning, we cannot return our extra value in a
backwards compatible way. Instead, we require the caller to
add an extra explicit flag to request the information.
The ident_person function, on the other hand, always returns
a scalar, so we are free to overload it in an array context.
Signed-off-by: Jeff King p...@peff.net
---
perl/Git.pm | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 497f420..1994ec1 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -737,7 +737,7 @@ sub remote_refs {
}
-=item ident ( TYPE | IDENTSTR )
+=item ident ( TYPE | IDENTSTR [, options] )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
@@ -750,6 +750,10 @@ and either returns it as a scalar string or as an array
with the fields parsed.
Alternatively, it can take a prepared ident string (e.g. from the commit
object) and just parse it.
+If the Cexplicit option is set to 1, the returned array will contain an
+additional boolean specifying whether the ident was configure explicitly by the
+user.
+
Cident_person returns the person part of the ident - name and email;
it can take the same arguments as Cident or the array returned by Cident.
@@ -763,17 +767,22 @@ The synopsis is like:
=cut
sub ident {
- my ($self, $type) = _maybe_self(@_);
- my $identstr;
+ my ($self, $type, %options) = _maybe_self(@_);
+ my ($identstr, $explicit);
if (lc $type eq lc 'committer' or lc $type eq lc 'author') {
- my @cmd = ('var', 'GIT_'.uc($type).'_IDENT');
+ my $uc = uc($type);
+ my @cmd = ('var', GIT_${uc}_IDENT, GIT_${uc}_EXPLICIT);
unshift @cmd, $self if $self;
- $identstr = command_oneline(@cmd);
+ ($identstr, $explicit) = command(@cmd);
} else {
$identstr = $type;
}
if (wantarray) {
- return $identstr =~ /^(.*) (.*) (\d+ [+-]\d{4})$/;
+ my @ret = $identstr =~ /^(.*) (.*) (\d+ [+-]\d{4})$/;
+ if ($options{explicit} defined $explicit) {
+ push @ret, $explicit if defined $explicit;
+ }
+ return @ret;
} else {
return $identstr;
}
@@ -781,8 +790,11 @@ sub ident {
sub ident_person {
my ($self, @ident) = _maybe_self(@_);
- $#ident == 0 and @ident = $self ? $self-ident($ident[0]) :
ident($ident[0]);
- return $ident[0] $ident[1];
+ $#ident == 0 and @ident = $self ?
+ $self-ident($ident[0], explicit = 1) :
+ ident($ident[0], explicit = 1);
+ my $ret = $ident[0] $ident[1];
+ return wantarray ? ($ret, @ident[3]) : $ret;
}
--
1.8.0.207.gdf2154c
--
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 6/6] send-email: do not prompt for explicit repo ident
If git-send-email is configured with sendemail.from, we will
not prompt the user for the From address of the emails.
If it is not configured, we prompt the user, but provide the
repo author or committer as a default. Even though we
probably have a sensible value for the default, the prompt
is a safety check in case git generated an incorrect
implicit ident string.
Now that Git.pm will tell us whether the ident is implicit or
explicit, we can stop prompting in the explicit case, saving
most users from having to see the prompt at all.
The test scripts need to be adjusted to not expect a prompt
for the sender, since they always have the author explicitly
defined in the environment. Unfortunately, we cannot
reliably test that prompting still happens in the implicit
case, as send-email will produce inconsistent results
depending on the machine config (if we cannot find a FQDN,
git var will barf, causing us to exit early; if we can,
send-email will continue but prompt).
Signed-off-by: Jeff King p...@peff.net
---
git-send-email.perl | 22 +-
t/t9001-send-email.sh | 5 ++---
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..0c49b32 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -436,9 +436,8 @@ if (0) {
}
}
-my ($repoauthor, $repocommitter);
-($repoauthor) = Git::ident_person(@repo, 'author');
-($repocommitter) = Git::ident_person(@repo, 'committer');
+my ($repoauthor, $author_explicit) = Git::ident_person(@repo, 'author');
+my ($repocommitter, $committer_explicit) = Git::ident_person(@repo,
'committer');
# Verify the user input
@@ -755,12 +754,17 @@ if (!$force) {
my $prompting = 0;
if (!defined $sender) {
- $sender = $repoauthor || $repocommitter || '';
- $sender = ask(Who should the emails appear to be from? [$sender] ,
- default = $sender,
- valid_re = qr/\@.*\./, confirm_only = 1);
- print Emails will be sent from: , $sender, \n;
- $prompting++;
+ ($sender, my $explicit) =
+ defined $repoauthor ? ($repoauthor, $author_explicit) :
+ defined $repocommitter ? ($repocommitter, $committer_explicit) :
+ ('', 0);
+ if (!$explicit) {
+ $sender = ask(Who should the emails appear to be from?
[$sender] ,
+ default = $sender,
+ valid_re = qr/\@.*\./, confirm_only = 1);
+ print Emails will be sent from: , $sender, \n;
+ $prompting++;
+ }
}
if (!@initial_to !defined $to_cmd) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 6c6af7d..c5d66cf 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -191,14 +191,13 @@ test_expect_success $PREREQ 'Show all headers' '
test_expect_success $PREREQ 'Prompting works' '
clean_fake_sendmail
- (echo Example f...@example.com
-echo t...@example.com
+ (echo t...@example.com
echo
) | GIT_SEND_EMAIL_NOTTY=1 git send-email \
--smtp-server=$(pwd)/fake.sendmail \
$patches \
2errors
- grep ^From: Example f...@example.com\$ msgtxt1
+ grep ^From: A U Thor aut...@example.com\$ msgtxt1
grep ^To: t...@example.com\$ msgtxt1
'
--
1.8.0.207.gdf2154c
--
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: Notes in format-patch
Junio C Hamano gits...@pobox.com writes:
Michael J Gruber g...@drmicha.warpmail.net writes:
Michael J Gruber venit, vidit, dixit 12.11.2012 15:18:
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the argument to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Notes:
v3 safeguards the hex buffer against reuse
builtin/replace.c | 16 ++--
t/t6050-replace.sh | 11 +++
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
By the way - Junio, is that the intented outcome of format-patch
--notes? I would rather put the newline between the note and the
diffstat...
I do not mind (actually I personally would prefer to see) a blank
line between the three-dash and Notes:, but I agree that we should
have a blank line before the diffstat block.
As the topic seems to be already in Peff's next, here is a trivial
fix for this in incremental form.
-- 8 --
Subject: format-patch: add a blank line between notes and diffstat
The last line of the note text comes immediately before the diffstat
block, making the latter unnecessarily harder to view.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
log-tree.c | 1 +
1 file changed, 1 insertion(+)
diff --git i/log-tree.c w/log-tree.c
index 712a22b..9303fd8 100644
--- i/log-tree.c
+++ w/log-tree.c
@@ -683,6 +683,7 @@ void show_log(struct rev_info *opt)
opt-shown_dashes = 1;
}
strbuf_addstr(msgbuf, ctx.notes_message);
+ strbuf_addch(msgbuf, '\n');
}
if (opt-show_log_size) {
--
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: [BUG] gitweb: XSS vulnerability of RSS feed
On Tue, Nov 13, 2012 at 09:44:06AM -0500, Drew Northup wrote: I don't buy the argument that we don't need to clean up the input as well. There are scant few of us that are going to name a file scriptalert(Something Awful)/script in this world (I am probably one of them). Input validation is key to keeping problems like this from coming up repeatedly as those writing the guts of programs are typically more interested in getting the assigned task done and reporting the output to the user in a safe manner. Oh, you absolutely do need to clean up the input side. And we do. Notice how validate_pathname cleans out dots that could allow an attacker to do a ../../etc/passwd attack. But the input validation is _different_ than the output escaping. We are turning arbitrary junk from the user into something we know is safe to treat as a filename. Our goal is protecting the filesystem and the server, and we do that already. Protecting the browser on output is a different problem, and happens only when we are sending to the browser. As far as people will not use script in their filenames, the end-game to any quoting or blacklist fix is that we need to escape or black _all_ HTML. Because whether it is b or script, it is still wrong. Are you as comfortable saying that nobody will ever have a or in their filename? 3. Your filter is too simplistic. At the very least, it would not filter out SCRIPT. I am not up to date on all of the sneaking-around-HTML-filters attacks that are available these days, but I wonder if one could also get around it using XML entities or similar. You will note that I said a more definitive fix is in order in my original. In other words, I claimed it to be utterly incomplete to start with. Sorry if I came off as too harsh. My intent was to guide you in the right direction for the definitive fix. The fact that I ended up rolling the patch myself was just because my probably something like this ended with everybody saying yeah, that, and it seemed simpler to just roll a test and be done. I think the right answer is going to be a well-placed call to esc_html. This already happens automatically when we go through the CGI element-building functions, but obviously we failed to make the call when building the output manually. This is a great reason why template languages which default to safe expansion should always be used. Unfortunately, gitweb is living in 1995 in terms of web frameworks. Escaping the output protects the user, but it DOES NOT protect the server. We MUST handle both possibilities. Right. But I think we already do, via validate_pathname. If that is not the case, please point it out. Besides, inserting one call to esc_html only fixes one attack path. I didn't look to see if all others were already covered. Properly quoting output is something that the web framework should do for you. gitweb uses CGI.pm, which does help with that, but we do not use it consistently. If there are other problematic areas, I think the best path forward is to use our framework more. -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: [PATCH] send-email: add proper default sender
On Tue, Nov 13, 2012 at 08:13:04AM -0800, Junio C Hamano wrote: That's right, AUTHOR_IDENT would fall back to the default email and full name. Yeah, I find that somewhat questionable in the current behavior, and I'd consider it a bug. Typically we prefer the committer ident when given a choice (e.g., for writing reflog entries). Just to make sure I follow the discussion correctly, do you mean that the bug is that we pick a fuzzy AUTHOR when COMMITTER is specified more concretely and we usually use COMMIITTER for this kind of thing in the first place but send-email does not in this case (I do not see git var GIT_AUTHOR_IDENT returning value from the implicit logic as a bug in this case---just making sure). Having discussed more, I think there are two questionable things: 1. Preferring author over committer 2. Failing to fall back to committer when author is implicit or bogus (because git var dies). I think (1) may fall into the this is not how I would do it today, but it is not worth a possible regression category. I think (2) might be worth fixing, though. Certainly when the author is bogus (by IDENT_STRICT rules), which I think was the original intent of the $repoauthor || $repocommitter code. Probably when the author ident is implicit, though that is more hazy to me. For a change with low benefit/cost ratio like this, the best course of action often is to stop paying attention to the thread that has become unproductive and venomous, and resurrect the topic after people forgot about it and doing it right yourself ;-). I came to the same conclusion, but decided to simply do it right now while it was in my head. Hopefully we can progress by reviewing the series I just posted. -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: [PATCH] send-email: add proper default sender
On Tue, Nov 13, 2012 at 12:35 AM, Jeff King p...@peff.net wrote: On Sun, Nov 11, 2012 at 06:06:50PM +0100, Felipe Contreras wrote: There's no point in asking this over and over if the user already properly configured his/her name and email. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I got really tired of 'git send-email' always asking me from which address to send mails... that's already configured. It should be defaulting to your regular git ident, and you just have to hit enter, right? I think it's probably reasonable to skip that enter in most cases. But I'm not sure why we ever asked in the first place. What do people input there if they are not taking the default? I usually input Linus Torvalds torva...@linux-foundation.org, to give my patch high priority ;-) -- 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: [BUG] gitweb: XSS vulnerability of RSS feed
On Tue, Nov 13, 2012 at 6:04 PM, Jeff King p...@peff.net wrote: On Tue, Nov 13, 2012 at 09:44:06AM -0500, Drew Northup wrote: Besides, inserting one call to esc_html only fixes one attack path. I didn't look to see if all others were already covered. Properly quoting output is something that the web framework should do for you. gitweb uses CGI.pm, which does help with that, but we do not use it consistently. If there are other problematic areas, I think the best path forward is to use our framework more. Well, calling CGI.pm a _framework_ is overly generous, but it does include some HTML generation subroutines / methods, and gitweb makes use of them, especially $cgi-a() for links. But it cannot help in this case, because here we are generating XML: RSS or Atom feed. There was proposal some time ago to switch to using XML::FeedPP or XML::Atom::Feed + XML::RSS::Feed for feed generation. Perhaps it is high time to switch to some Perl web (micro)framework, like Dancer, Mojolicious or Catalyst... but not requiring extra modules has its advantages (and there always exist Gitalist). -- Jakub Narebski -- 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] send-email: add proper default sender
Jeff King p...@peff.net writes: On Tue, Nov 13, 2012 at 08:13:04AM -0800, Junio C Hamano wrote: That's right, AUTHOR_IDENT would fall back to the default email and full name. Yeah, I find that somewhat questionable in the current behavior, and I'd consider it a bug. Typically we prefer the committer ident when given a choice (e.g., for writing reflog entries). Just to make sure I follow the discussion correctly, do you mean that the bug is that we pick a fuzzy AUTHOR when COMMITTER is specified more concretely and we usually use COMMIITTER for this kind of thing in the first place but send-email does not in this case (I do not see git var GIT_AUTHOR_IDENT returning value from the implicit logic as a bug in this case---just making sure). Having discussed more, I think there are two questionable things: 1. Preferring author over committer 2. Failing to fall back to committer when author is implicit or bogus (because git var dies). I think (1) may fall into the this is not how I would do it today, but it is not worth a possible regression category. I think (2) might be worth fixing, though. Certainly when the author is bogus (by IDENT_STRICT rules), which I think was the original intent of the $repoauthor || $repocommitter code. Probably when the author ident is implicit, though that is more hazy to me. I agree with both points. 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 5/6] Git.pm: teach ident to query explicitness
On Tue, Nov 13, 2012 at 09:23:00AM -0800, Matt Kraai wrote:
Minor nits:
On Tue, Nov 13, 2012 at 11:53:20AM -0500, Jeff King wrote:
@@ -750,6 +750,10 @@ and either returns it as a scalar string or as an
array with the fields parsed.
Alternatively, it can take a prepared ident string (e.g. from the commit
object) and just parse it.
+If the Cexplicit option is set to 1, the returned array will contain an
+additional boolean specifying whether the ident was configure explicitly
by the
s/configure/configured/
Thanks.
if (wantarray) {
- return $identstr =~ /^(.*) (.*) (\d+ [+-]\d{4})$/;
+ my @ret = $identstr =~ /^(.*) (.*) (\d+ [+-]\d{4})$/;
+ if ($options{explicit} defined $explicit) {
+ push @ret, $explicit if defined $explicit;
Isn't the test on this line redundant given that defined $explicit is
already guaranteed by the condition on the previous line?
Yes, thanks (left over from an earlier attempt that tried to avoid
having $options{explicit}).
-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: Notes in format-patch
Junio C Hamano gits...@pobox.com writes:
As the topic seems to be already in Peff's next, here is a trivial
fix for this in incremental form.
-- 8 --
Subject: format-patch: add a blank line between notes and diffstat
The last line of the note text comes immediately before the diffstat
block, making the latter unnecessarily harder to view.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
log-tree.c | 1 +
1 file changed, 1 insertion(+)
diff --git i/log-tree.c w/log-tree.c
index 712a22b..9303fd8 100644
--- i/log-tree.c
+++ w/log-tree.c
@@ -683,6 +683,7 @@ void show_log(struct rev_info *opt)
opt-shown_dashes = 1;
}
strbuf_addstr(msgbuf, ctx.notes_message);
+ strbuf_addch(msgbuf, '\n');
}
if (opt-show_log_size) {
... and it is broken X-.
The blank line should be added before the diffstat, not after the
notes message (t3307 shows a case where we give notes without
diffstat, and we shouldn't be adding an extra blank line in that
case.
--
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
What's cooking in git.git (Nov 2012, #03; Tue, 13)
What's cooking in git.git (Nov 2012, #03; Tue, 13) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. This is my final what's cooking as interim maintainer. I didn't graduate anything to master, but I updated my plans for each topic to give Junio an idea of where I was. You can find the changes described here in the integration branches of my repository at: git://github.com/peff/git.git Until Junio returns, kernel.org and the other usual places will not be updated. -- [New Topics] * jk/maint-gitweb-xss (2012-11-12) 1 commit - gitweb: escape html in rss title Fixes an XSS vulnerability in gitweb. Will merge to 'next'. * jk/send-email-sender-prompt (2012-11-13) 6 commits - send-email: do not prompt for explicit repo ident - Git.pm: teach ident to query explicitness - var: provide explicit/implicit ident information - var: accept multiple variables on the command line - ident: keep separate explicit flags for author and committer - ident: make user_ident_explicitly_given private Avoid annoying sender prompt in git-send-email, but only when it is safe to do so. Needs review. * mg/replace-resolve-delete (2012-11-13) 1 commit - replace: parse revision argument for -d Be more user friendly to people using git replace -d. Will merge to 'next'. * ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on newer cygwin. Will merge to 'next'. -- [Stalled] * rc/maint-complete-git-p4 (2012-09-24) 1 commit (merged to 'next' on 2012-10-29 at af52cef) + Teach git-completion about git p4 Comment from Pete will need to be addressed in a follow-up patch. * as/test-tweaks (2012-09-20) 7 commits - tests: paint unexpectedly fixed known breakages in bold red - tests: test the test framework more thoroughly - [SQUASH] t/t-basic.sh: quoting of TEST_DIRECTORY is screwed up - tests: refactor mechanics of testing in a sub test-lib - tests: paint skipped tests in bold blue - tests: test number comes first in 'not ok $count - $message' - tests: paint known breakages in bold yellow Various minor tweaks to the test framework to paint its output lines in colors that match what they mean better. Has the is this really blue? issue Peff raised resolved??? * jc/maint-name-rev (2012-09-17) 7 commits - describe --contains: use name-rev --algorithm=weight - name-rev --algorithm=weight: tests and documentation - name-rev --algorithm=weight: cache the computed weight in notes - name-rev --algorithm=weight: trivial optimization - name-rev: --algorithm option - name_rev: clarify the logic to assign a new tip-name to a commit - name-rev: lose unnecessary typedef git name-rev names the given revision based on a ref that can be reached in the smallest number of steps from the rev, but that is not useful when the caller wants to know which tag is the oldest one that contains the rev. This teaches a new mode to the command that uses the oldest ref among those which contain the rev. I am not sure if this is worth it; for one thing, even with the help from notes-cache, it seems to make the describe --contains even slower. Also the command will be unusably slow for a user who does not have a write access (hence unable to create or update the notes-cache). Stalled mostly due to lack of responses. * jc/xprm-generation (2012-09-14) 1 commit - test-generation: compute generation numbers and clock skews A toy to analyze how bad the clock skews are in histories of real world projects. Stalled mostly due to lack of responses. * jc/blame-no-follow (2012-09-21) 2 commits - blame: pay attention to --no-follow - diff: accept --no-follow option Teaches --no-follow option to git blame to disable its whole-file rename detection. Stalled mostly due to lack of responses. * jc/doc-default-format (2012-10-07) 2 commits - [SQAUSH] allow cd Doc* make DEFAULT_DOC_TARGET=... - Allow generating a non-default set of documentation Need to address the installation half if this is to be any useful. * mk/maint-graph-infinity-loop (2012-09-25) 1 commit - graph.c: infinite loop in git whatchanged --graph -m The --graph code fell into infinite loop when asked to do what the code did not expect ;-) Anybody who worked on --graph wants to comment? Stalled mostly due to lack of responses. * jc/add-delete-default (2012-08-13) 1 commit - git add: notice removal of tracked paths by default git add dir/ updated modified files and added new files, but does not notice removed files, which may be Huh? to some users. They can of course use git add -A dir/, but why should they? Resurrected from graveyard, as I thought it was a worthwhile thing to do in the longer
Re: [PATCH 14/13] test-wildmatch: avoid Windows path mangling
Am 13.11.2012 11:06, schrieb Nguyễn Thái Ngọc Duy: On Windows, arguments starting with a forward slash is mangled as if it were full pathname. This causes the patterns beginning with a slash not to be passed to test-wildmatch correctly. Avoid mangling by never accepting patterns starting with a slash. Those arguments must be rewritten with a leading XXX (e.g. /abc becomes XXX/abc), which will be removed by test-wildmatch itself before feeding the patterns to wildmatch() or fnmatch(). Reported-by: Johannes Sixt j...@kdbg.org Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- On Sun, Nov 11, 2012 at 5:47 PM, Junio C Hamano gits...@pobox.com wrote: The title taken together with the above explanation makes it sound as if wildmatch code does not work with the pattern /foo on Windows at all and to avoid the issue (instead of fixing the breakage) this patch removes such tests OK how about this? Thanks, the patch lets the tests pass on Windows. -- Hannes -- 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 15/13] compat/fnmatch: fix off-by-one character class's length check
Am 11.11.2012 11:13, schrieb Nguyễn Thái Ngọc Duy: - if (c1 == CHAR_CLASS_MAX_LENGTH) + if (c1 CHAR_CLASS_MAX_LENGTH) Nice catch! With this one and 14/13, all tests in t3070 pass on Windows. -- Hannes -- 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: Notes in format-patch
Junio C Hamano gits...@pobox.com writes:
... and it is broken X-.
The blank line should be added before the diffstat, not after the
notes message (t3307 shows a case where we give notes without
diffstat, and we shouldn't be adding an extra blank line in that
case.
Second try.
-- 8 --
Subject: format-patch: add a blank line between notes and diffstat
The last line of the note text comes immediately before the diffstat
block, making the latter unnecessarily harder to view.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
log-tree.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git c/log-tree.c w/log-tree.c
index 712a22b..4f86def 100644
--- c/log-tree.c
+++ w/log-tree.c
@@ -727,15 +727,16 @@ int log_tree_diff_flush(struct rev_info *opt)
}
if (opt-loginfo !opt-no_commit_id) {
- /* When showing a verbose header (i.e. log message),
-* and not in --pretty=oneline format, we would want
-* an extra newline between the end of log and the
-* output for readability.
-*/
show_log(opt);
if ((opt-diffopt.output_format ~DIFF_FORMAT_NO_OUTPUT)
opt-verbose_header
opt-commit_format != CMIT_FMT_ONELINE) {
+ /*
+* When showing a verbose header (i.e. log message),
+* and not in --pretty=oneline format, we would want
+* an extra newline between the end of log and the
+* diff/diffstat output for readability.
+*/
int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
if (opt-diffopt.output_prefix) {
struct strbuf *msg = NULL;
@@ -743,11 +744,21 @@ int log_tree_diff_flush(struct rev_info *opt)
opt-diffopt.output_prefix_data);
fwrite(msg-buf, msg-len, 1, stdout);
}
- if (!opt-shown_dashes) {
- if ((pch opt-diffopt.output_format) == pch)
- printf(---);
- putchar('\n');
- }
+
+ /*
+* We may have shown three-dashes line early
+* between notes and the log message, in which
+* case we only want a blank line after the
+* notes without (an extra) three-dashes line.
+* Otherwise, we show the three-dashes line if
+* we are showing the patch with diffstat, but
+* in that case, there is no extra blank line
+* after the three-dashes line.
+*/
+ if (!opt-shown_dashes
+ (pch opt-diffopt.output_format) == pch)
+ printf(---);
+ putchar('\n');
}
}
diff_flush(opt-diffopt);
--
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: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
On Tue, Nov 13, 2012 at 11:15 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Felipe Contreras venit, vidit, dixit 12.11.2012 23:47: On Mon, Nov 12, 2012 at 10:41 PM, Jeff King p...@peff.net wrote: On Sun, Nov 11, 2012 at 07:48:14PM +0100, Felipe Contreras wrote: 3. Exporters should not use it if they have any broken-down representation at all. Even knowing that the first half is a human name and the second half is something else would give it a better shot at cleaning than fast-import would get. I'm not sure what you mean by this. If they have name and email, then sure, it's easy. But not as easy as just printing it. What if you have this: name=Peff angle brackets King email=p...@peff.net Concatenating them does not produce a valid git author name. Sending the concatenation through fast-import's cleanup function would lose information (namely, the location of the boundary between name and email). Right. Unfortunately I'm not aware of any DSCM that does that. Similarly, one might have other structured data (e.g., CVS username) where the structure is a useful hint, but some conversion to name+email is still necessary. CVS might be the only one that has such structured data. I think in subversion the username has no meaning. A 'felipec' subversion username is as bad as a mercurial 'felipec' username. In subversion, the username has the clearly defined meaning of being a username on the subversion host. If the host is, e.g., a sourceforge site then I can easily look up the user profile and convert the username into a valid e-mail address (username@users.sf.net). That is the advantage that the exporter (together with user knowledge) has over the importer. If the initial clone process aborts after every single unknown user it's no fun, of course. On the other hand, if an incremental clone (fetch) let's commits with unknown author sneak in it's no fun either (because I may want to fetch in crontab and publish that converted beast automatically). That is why I proposed neither approach. Most conveniently, the export side of a remote helper would - do obvious automatic lossless transformations - use an author map for other names This should be done by fast-import. It doesn't make any sense that every remote helper and fast-exporter out there have their own way of mapping authors (or none). - For names not covered by the above (or having an empty map entry): Stop exporting commits but continue parsing commits and amend the author map with any unknown usernames (empty entry), and warn the user. (crontab script can notify me based on the return code.) Stop exporting commits but continue parsing commits? I don't know what that means. fast-import should try it's best to clean it up, warn the user, sure, but also store the missing entry on a file, so that it can be filed later (if the user so wishes). If the cloning involves a foreign clone (like the hg clone behind the scene) then the runtime of the second pass should be much smaller. In principle, one could even store all blobs and trees on the first run and skip that step on the second, but that would rely on immutability on the foreign side, so I dunno. (And to check the sha1, we have to get the blob anyways.) No. There's no concept of partial clones... Either you clone, or you don't. Wait if the remote helper didn't notice that the author was bad? fast-import could just just leave everything up to that point, warn abut what happened, and exit, but the exporter side would die in the middle of exporting, and it might end up in a bad state, not saving marks, or who knows what. It wouldn't work. The cloning should be full, and the bad authors stored in a scaffold author map. As for the format for incomplete entries (foo some@where), a technical guideline should suffice for those that follow guidelines. fast-import should do that. Cheers. -- Felipe Contreras -- 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] Add tcsh-completion support to contrib by using git-completion.bash
On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam marc.khou...@gmail.com wrote:
this patch allows tcsh-users to get the benefits of the awesome
git-completion.bash script. It could also help other shells do the same.
Maybe you can try to take a look at the same for zsh:
http://article.gmane.org/gmane.comp.version-control.git/208173
---
contrib/completion/git-completion.bash | 53
+++-
contrib/completion/git-completion.tcsh | 34
2 files changed, 86 insertions(+), 1 deletions(-)
create mode 100755 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..6d4b57a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,4 +1,6 @@
-#!bash
+#!/bin/bash
+# The above line is important as this script can be executed when used
+# with another shell such as tcsh
#
# bash/zsh completion support for core Git.
#
@@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
if [ Cygwin = $(uname -o 2/dev/null) ]; then
__git_complete git.exe __git_main
fi
+
+# Method that will output the result of the completion done by
+# the bash completion script, so that it can be re-used in another
+# context than the bash complete command.
+# It accepts 1 to 2 arguments:
+# 1: The command-line to complete
+# 2: The index of the word within argument #1 in which the cursor is
+#located (optional). If parameter 2 is not provided, it will be
+#determined as best possible using parameter 1.
+_git_complete_with_output ()
+{
+ # Set COMP_WORDS to the command-line as bash would.
+ COMP_WORDS=($1)
+
+ # Set COMP_CWORD to the cursor location as bash would.
+ if [ -n $2 ]; then
+ COMP_CWORD=$2
+ else
+ # Assume the cursor is at the end of parameter #1.
+ # We must check for a space as the last character which will
+ # tell us that the previous word is complete and the cursor
+ # is on the next word.
+ if [ ${1: -1} == ]; then
+ # The last character is a space, so our
location is at the end
+ # of the command-line array
+ COMP_CWORD=${#COMP_WORDS[@]}
+ else
+ # The last character is not a space, so our
location is on the
+ # last word of the command-line array, so we
must decrement the
+ # count by 1
+ COMP_CWORD=$((${#COMP_WORDS[@]}-1))
+ fi
+ fi
+
+ # Call _git() or _gitk() of the bash script, based on the first
+ # element of the command-line
+ _${COMP_WORDS[0]}
You might want to use __${COMP_WORDS[0]}_main instead.
+
+ # Print the result that is stored in the bash variable ${COMPREPLY}
+ for i in ${COMPREPLY[@]}; do
+ echo $i
+ done
+}
+
+if [ -n $1 ] ; then
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
+fi
Why do you need this function in this file? You can very easily add
this function to git-completion.tcsh.
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100755
index 000..7b7baea
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,34 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# This script makes use of the git-completion.bash script to
+# determine the proper completion for git commands under tcsh.
+#
+# To use this completion script:
+#
+#1) Copy both this file and the bash completion script to your
${HOME} directory
+# using the names ${HOME}/.git-completion.tcsh and
${HOME}/.git-completion.bash.
+#2) Add the following line to your .tcshrc/.cshrc:
+#source ${HOME}/.git-completion.tcsh
+
+# One can change the below line to use a different location
+set __git_tcsh_completion_script = ${HOME}/.git-completion.bash
+
+# Check that the user put the script in the right place
+if ( ! -e ${__git_tcsh_completion_script} ) then
+ echo ERROR in git-completion.tcsh script. Cannot find:
${__git_tcsh_completion_script}. Git completion will not work.
+ exit
+endif
+
+# Make the script executable if it is not
+if ( ! -x ${__git_tcsh_completion_script} ) then
+ chmod u+x ${__git_tcsh_completion_script}
+endif
Why not just source it?
+complete git 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
+complete gitk 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
Re: checkout from neighbour branch undeletes a path?
Hello. 2012/11/13 08:43:31 -0800 Junio C Hamano gits...@pobox.com = To Peter Vereshagin : JCH Peter Vereshagin pe...@vereshagin.org writes: JCH JCH Am wondering if 'checkout branch path' undeletes the files? JCH JCH git checkout branch path (by the way, branch does not have to be JCH a branch name; any commit object name would do, like git checkout JCH HEAD^^ hello.c) is a way to check out named path(s) out of the JCH named commit. JCH JCH If the commit branch has path in it, its contents are checked JCH out to path in your current working tree (and the entry in the JCH index updated to match it). JCH JCH If you happen to have removed path in your current working tree JCH before running that command, it might look as if there is some JCH undelete going on, but that is a wrong way to look at things. The JCH version of path in the branch may or may not be similar to what JCH you have removed earlier. JCH Hello. I solved my problem by mean of 'git rm' instead of 'rm'. I knew what you said here. Shortly, the difference for my case was: - I check out the pathdir from the commit in which the pathdir/file00 was already removed. - The current branch 'branch01' has no idea the file00 was removed. But I removed file00 and this is what 'branch01' assumes when I commit n ext time. But git assumes I need 'file00' although it doesn't exist in the commit I checkout path from. It doesn't exist by itself before I checkout that path neither. How can I know which one of the 'file00' versions is being checked out: the one that did exist in the 'branch00' (the where I checkout path from) before I removed it or the one existing in HEAD but not in the work-tree? And why this and not that? If it is the one that exists in a current branch but was deleted from trhe work-tree [d4f7c70] than why it is being checked out not from the commit supplied as an argument to git? If it is the one that existed [c3e78ff] before the commit I checkout path from than why it is being checked out while it doesn't exist in that commit already? Thank you. -- Peter Vereshagin pe...@vereshagin.org (http://vereshagin.org) pgp: A0E26627 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
Jeff King wrote: On Sat, Nov 10, 2012 at 06:33:38PM +, Ramsay Jones wrote: We should probably wrap it. I'm planning to queue this on top of Chris's patch: Unfortunately, I haven't had time yet to test this patch. (Early this week, I went into hospital for a minor surgical procedure - I have not yet fully recovered). The patch looks good and I don't anticipate any problems. I will hopefully test it soon (I see it's in pu now) and let you know. Thanks. I merged it to next on Friday, so we will see if anybody screams. But please take your time and recover. Git will wait. :) I have tested this patch and, as expected, it fixes things up for me. (To be more precise: the current next branch works, but if I revert commit c2b3af05, then t9604-cvsimport-timestamps.sh fails in the same way as before!) Thanks! ATB, Ramsay Jones -- 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: [regression] Newer gits cannot clone any remote repos
Douglas Mencken wrote: *Any* git clone fails with: fatal: premature end of pack file, 106 bytes missing fatal: index-pack failed At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5 then, and it worked. Then I tried 1.7.12.2, but it fails the same way as 1.8.0. So I decided to git bisect. b8a2486f1524947f232f657e9f2ebf44e3e7a243 is the first bad commit ``index-pack: support multithreaded delta resolving'' This looks like the same problem I had on cygwin, which lead to commit c0f86547c (index-pack: Disable threading on cygwin, 26-06-2012). I didn't notice which platform you are on, but maybe you also have a thread-unsafe pread()? Could you try re-building git with the NO_THREAD_SAFE_PREAD build variable set? HTH. ATB, Ramsay Jones -- 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 nd/wildmatch] Correct Git's version of isprint and isspace
Hi.
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
Git's ispace does not include 11 and 12. Git's isprint includes
control space characters (10-13). According to glibc-2.14.1 on C
locale on Linux, this is wrong. This patch fixes it.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
I wrote a small C program to compare the result of all is* functions
that Git replaces against the libc version. These are the only ones that
differ. Which matches what Jan Schönherr commented.
ctype.c | 6 +++---
git-compat-util.h | 11 ++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/ctype.c b/ctype.c
index 0bfebb4..71311a3 100644
--- a/ctype.c
+++ b/ctype.c
@@ -14,11 +14,11 @@ enum {
P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
X = GIT_CNTRL,
U = GIT_PUNCT,
- Z = GIT_CNTRL | GIT_SPACE
+ Z = GIT_CNTRL_SPACE
};
-const unsigned char sane_ctype[256] = {
- X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
+const unsigned int sane_ctype[256] = {
+ X, X, X, X, X, X, X, X, X, Z, Z, Z, Z, Z, X, X, /* 0.. 15 */
X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
An alternative to switching from 1-byte to 4-byte values (don't we have
a 2-byte datatype?), would be to free up GIT_CNTRL and simply do:
#define iscntrl(x) ((x) 0x20)
diff --git a/git-compat-util.h b/git-compat-util.h
index 02f48f6..4ed3f94 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
[...]
@@ -483,9 +483,10 @@ extern const unsigned char sane_ctype[256];
#define GIT_PATHSPEC_MAGIC 0x20
#define GIT_CNTRL 0x40
#define GIT_PUNCT 0x80
-#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] (mask)) != 0)
+#define GIT_SPACE 0x100
+#define sane_istest(x,mask) ((sane_ctype[(unsigned int)(x)] (mask)) != 0)
That should better be left (unsigned char)? We might access values after the
array otherwise.
(That said, it wasn't really correct before either, when there really is a
possibility that x = 0x100.)
Regards
Jan
PS: It looks like my isprint() version was given precedence over your
isprint() version during the merge into next. That should also be sorted out,
but I've no idea which one is actually better: two comparisons versus one
cache lookup and a bitop... (though my guess is that comparisons are cheaper,
but then we should also convert isdigit()...)
--
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 nd/wildmatch] Correct Git's version of isprint and isspace
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy: Git's isprint includes control space characters (10-13). According to glibc-2.14.1 on C locale on Linux, this is wrong. This patch fixes it. isprint() is not in master, yet. Can we perhaps still introduce it in such a way that we never have an incorrect version in master's history? And could you please update test-ctype.c to match the change to isspace()? The tests there just documented the status quo before I made changes to ctype.c long ago, so it's definitions are just as correct (or wrong) as the original implementation. Thanks, René -- 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 nd/wildmatch] Correct Git's version of isprint and isspace
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy: Git's ispace does not include 11 and 12. [...] According to glibc-2.14.1 on C locale on Linux, this is wrong. 11 and 12 being vertical tab (\v) and form-feed (\f). This lack goes back to the introduction of git's own character classifier macros seven years ago in 4546738b (Unlocalized isspace and friends). Linus, do you remember if you left them out on purpose? Thanks, René -- 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] send-email: stop asking when we have an ident
From: Felipe Contreras 2nd felipe.contrera...@gmail.com
Currently we keep getting questions even when the user has properly
configured his full name and password:
Who should the emails appear to be from?
[Felipe Contreras felipe.contre...@gmail.com]
And once a question pops up, other questions are turned on. This is
annoying.
The reason this is safe is because currently the script fails completely
when the autohor (or committer) is not correct, so we won't even be
reaching this point in the code.
The scenarios, and the current situation:
1) No information at all, no fully qualified domain name
fatal: empty ident name (for felipec@nysa.(none)) not allowed
2) Only full name
fatal: unable to auto-detect email address (got 'felipec@nysa.(none)')
3) Full name + fqdm
Who should the emails appear to be from?
[Felipe Contreras feli...@nysa.felipec.org]
4) Full name + EMAIL
Who should the emails appear to be from?
[Felipe Contreras felipe.contre...@gmail.com]
5) User configured
6) GIT_COMMITTER
7) GIT_AUTHOR
All these are the same as 4)
After this patch:
1) 2) won't change: git send-email would still die
4) 5) 6) 7) will change: git send-email won't ask the user
This is good, that's what we would expect, because the identity is
explicit.
3) will change: git send-email won't ask the user
This is bad, because we will try with an address such as
'feli...@nysa.felipec.org', which is most likely not what the user
wants, but the user will get warned by default, and if not, most likley
the sending won't work, which the user can easily fix.
The worst possible scenario is that such a mail address does work, and
the user sends an email from that addres unintentionally, when in fact
the user expected to correct that address in the propmpt.
This is a very, very, very unlikely scenario, with many dependencies:
1) No configured user.name/user.email
2) No specified $EMAIL
3) No configured sendemail.from
4) No specified --from argument
5) A fully qualified domain name
6) A full name in the geckos field
7) A sendmail configuration that allows sending from this domain name
8) confirm=never, or
8.1) confirm configuration not hitting, or
8.2) Getting the error, not being aware of it
9) The user expecting to correct this address in the prompt
In a more likely scenario where 7) is not the case (can't send from
nysa.felipec.org), the user will simply see the mail was not sent
properly, and fix the problem.
The much more likely scenario though, is where 5) is not the case
(nysa.(none)), and git send-email will fail right away like it does now.
So the likelyhood of this affecting anybody seriously is very very slim,
and the chances of this affecting somebody slightly are still very
small. The vast majority, if not all, of git users won't be affected
negatively, and a lot will benefit from this.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-send-email.perl | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index aea66a0..503e551 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -748,16 +748,11 @@ if (!$force) {
}
}
-my $prompting = 0;
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
- $sender = ask(Who should the emails appear to be from? [$sender] ,
- default = $sender,
- valid_re = qr/\@.*\./, confirm_only = 1);
- print Emails will be sent from: , $sender, \n;
- $prompting++;
}
+my $prompting = 0;
if (!@initial_to !defined $to_cmd) {
my $to = ask(Who should the emails be sent to (if any)? ,
default = ,
--
1.8.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
Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
@@ -14,11 +14,11 @@ enum {
P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
X = GIT_CNTRL,
U = GIT_PUNCT,
- Z = GIT_CNTRL | GIT_SPACE
+ Z = GIT_CNTRL_SPACE
};
-const unsigned char sane_ctype[256] = {
- X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
+const unsigned int sane_ctype[256] = {
+ X, X, X, X, X, X, X, X, X, Z, Z, Z, Z, Z, X, X, /* 0.. 15 */
X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
diff --git a/git-compat-util.h b/git-compat-util.h
index 02f48f6..4ed3f94 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -474,8 +474,8 @@ extern const char tolower_trans_tbl[256];
#undef ispunct
#undef isxdigit
#undef isprint
-extern const unsigned char sane_ctype[256];
-#define GIT_SPACE 0x01
+extern const unsigned int sane_ctype[256];
+#define GIT_CNTRL_SPACE 0x01
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
#define GIT_GLOB_SPECIAL 0x08
@@ -483,9 +483,10 @@ extern const unsigned char sane_ctype[256];
#define GIT_PATHSPEC_MAGIC 0x20
#define GIT_CNTRL 0x40
#define GIT_PUNCT 0x80
-#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] (mask)) != 0)
+#define GIT_SPACE 0x100
+#define sane_istest(x,mask) ((sane_ctype[(unsigned int)(x)] (mask)) != 0)
#define isascii(x) (((x) ~0x7f) == 0)
-#define isspace(x) sane_istest(x,GIT_SPACE)
+#define isspace(x) sane_istest(x,GIT_SPACE | GIT_CNTRL_SPACE)
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
@@ -493,7 +494,7 @@ extern const unsigned char sane_ctype[256];
#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL |
GIT_REGEX_SPECIAL)
-#define iscntrl(x) (sane_istest(x,GIT_CNTRL))
+#define iscntrl(x) (sane_istest(x,GIT_CNTRL | GIT_CNTRL_SPACE))
#define ispunct(x) sane_istest(x, GIT_PUNCT | GIT_REGEX_SPECIAL | \
GIT_GLOB_SPECIAL | GIT_PATHSPEC_MAGIC)
#define isxdigit(x) (hexval_table[x] != -1)
So we have two properties that overlap:
SS
You seem to generate partions:
XXXYZ
then assign individual bits to each partition. Now each entry in the
lookup table has only one bit set. Then you define isxxx() to check for
one of the two possible bits:
iscntrl is X or Y
isspace is Y or Z
But shouldn't you just assign one bit for S and another one for C, have
entries in the lookup table with more than one bit set, and check for
only one bit in the isxxx macro?
That way you don't run out of bits as easily as you do with this patch.
-- Hannes
--
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 nd/wildmatch] Correct Git's version of isprint and isspace
On Tue, Nov 13, 2012 at 11:15 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Linus, do you remember if you left them out on purpose? Umm, no. I have to wonder why you care? As far as I'm concerned, the only valid space is space, TAB and CR/LF. Anything else is *noise*, not space. What's the reason for even caring? Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
On Tue, Nov 13, 2012 at 11:40 AM, Linus Torvalds torva...@linux-foundation.org wrote: I have to wonder why you care? As far as I'm concerned, the only valid space is space, TAB and CR/LF. Anything else is *noise*, not space. What's the reason for even caring? Btw, expanding the whitespace selection may actually be very counter-productive. It is used primarily for things like removing extraneous space at the end of lines etc, and for that, the current selection of SPACE, TAB and LF/CR is the right thing to do. Adding things like FF etc - that are *technically* whitespace, but aren't the normal kind of silent whitespace - is potentially going to change things too much. People might *want* a form-feed in their messages, for all we know. So I really object to changing things just because. There's a reason we do our own ctype.c: it avoids the crazy crap. It avoids the idiotic localization issues, and it avoids the ambiguous cases. So just let it be, unless you have some major real reason to actually care about a real-world case. And if you do, please explain it. Don't change things just because. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Jeff King p...@peff.net writes: This is my final what's cooking as interim maintainer. I didn't graduate anything to master, but I updated my plans for each topic to give Junio an idea of where I was. After exploding the first-parent history between your master..pu into component topics and recreating one new merge-fix for nd/wildmatch topic, I think I now know how to rebuild your integration branches. I still haven't caught up with the past discussions (and still am slightly jetlagged), but I think I can take it over from here with help from contributors. 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: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
Thanks for the review.
On Tue, Nov 13, 2012 at 6:14 AM, SZEDER Gábor sze...@ira.uka.de wrote:
Hi,
On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
Hi,
[...]
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
[...]
Thanks
Marc
---
contrib/completion/git-completion.bash | 53
+++-
contrib/completion/git-completion.tcsh | 34
2 files changed, 86 insertions(+), 1 deletions(-)
create mode 100755 contrib/completion/git-completion.tcsh
Please have a look at Documentation/SubmittingPatches to see how to
properly format the commit message, i.e. no greeting and sign-off in
the commit message part, and the S-o-b line should be the last before
the '---'.
Sorry about that, since I should have noticed it in the doc.
I will do my best to address all submission issues mentioned
when I post the next version of the patch.
Your patch seems to be severely line-wrapped. That document also
contains a few MUA-specific tips to help avoid that.
Other than that, it's a good description of the changes and
considerations. I agree that this approach seems to be the best from
the three.
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..6d4b57a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,4 +1,6 @@
-#!bash
+#!/bin/bash
+# The above line is important as this script can be executed when used
+# with another shell such as tcsh
See comment near the end.
Great suggestion below. I removed the above change.
+ # Set COMP_WORDS to the command-line as bash would.
+ COMP_WORDS=($1)
That comment is only true for older Bash versions. Since v4 Bash
splits the command line at characters that the readline library treats
as word separators when performing word completion. But the
completion script has functions to deal with both, so this shouldn't
be a problem.
I've updated the comment to be more general and left the code
the same since it is supported by the script.
+ # Print the result that is stored in the bash variable ${COMPREPLY}
Really? ;)
Removed :)
+ for i in ${COMPREPLY[@]}; do
+ echo $i
+ done
There is no need for the loop here to print the array one element per
line:
local IFS=$'\n'
echo ${COMPREPLY[*]}
Better. Thanks.
+if [ -n $1 ] ; then
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
Where does the second argument come from? Below you run this script
as '${__git_tcsh_completion_script} ${COMMAND_LINE}', i.e. $2 is
never set. Am I missing something?
This second argument is optional and, if present, will be put in
$COMP_CWORD. If not present, $COMP_CWORD must be computed
from $1. Also see comment above _git_complete_with_output ().
tcsh does not provide me with this information, so I cannot make use of it.
However, I thought it would be more future-proof to allow it for other shells
which may have that information.
It is not necessary for tcsh, so I can remove if you prefer?
+# Make the script executable if it is not
+if ( ! -x ${__git_tcsh_completion_script} ) then
+ chmod u+x ${__git_tcsh_completion_script}
+endif
Not sure about this. If I source a script to provide completion for a
command, then I definitely don't expect it to change file permissions.
However, even if the git completion script is not executable, you can
still run it with 'bash ${__git_tcsh_completion_script}'. This way
neither the user would need to set permissions, not the script would
need to set it behind the users back. Furthermore, this would also
make changing the shebang line unnecessary.
Very nice! Done.
+complete git 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
+complete gitk 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
Is the 'sort | uniq' really necessary? After the completion function
returns Bash automatically sorts the elements in COMPREPLY and removes
any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
completion.
On my machine, tcsh does not remove duplicates. It does sort the results
but that is done after I've run 'uniq', which is too late. I'm not
happy about this
either, but the other option is to improve git-completion.bash to
avoid duplicates,
which seemed less justified.
Does the git completion script returns any duplicates at all?
It does. 'help' is returned twice for example.
Also, when completing 'git checkout ' in the git repo, I can see multiple
'todo' branches, as well as 'master', 'pu', 'next', etc.
You can actually try it without tcsh by running my proposed version of
git-completion.bash like this:
cd git/contrib/completion
bash git-completion.bash git checkout | sort |
[PATCH] gitk - fix a problem with multiline author names
When commiting with git-commit no newline in the author string
is possible. But other git clients don't have the same validations
for the author name. And, it is possible to have a commit like:
commit
Merge: a b
Author: User Name
user.n...@domain.com
Date: Thu Nov 8 17:01:02 2012 +0100
Merge branch 'master' of ...
Note that the Author: string is split in two lines.
The git-log command work without problems with a commit like this, but
in gitk there is a problem because it splits the headers by a newline
character and that's why the email and time is not correctly parsed
and the history tree below this commit is not shown.
Signed-off-by: Tomo Krajina tkraj...@gmail.com
---
gitk-git/gitk | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 6f24f53..87300db 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1672,13 +1672,15 @@ proc parsecommit {id contents listed} {
foreach line [split $header \n] {
set line [split $line ]
set tag [lindex $line 0]
- if {$tag == author} {
-set audate [lrange $line end-1 end]
-set auname [join [lrange $line 1 end-2] ]
- } elseif {$tag == committer} {
-set comdate [lrange $line end-1 end]
-set comname [join [lrange $line 1 end-2] ]
- }
+if {$tag == author} {
+regexp -lineanchor {\nauthor([^]*)([^]*)\s+([^\n]+)}
$header all auname email audate
+set auname [string trim $auname]
+set auname $auname $email
+} elseif {$tag == committer} {
+regexp -lineanchor
{\ncommitter([^]*)([^]*)\s+([^\n]+)} $header all comname email
comdate
+set comname [string trim $comname]
+set comname $comname $email
+}
}
set headline {}
# take the first non-blank line of the comment as the headline
--
1.7.9.5
--
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] send-email: add proper default sender
On Tue, Nov 13, 2012 at 5:48 PM, Jeff King p...@peff.net wrote: On Tue, Nov 13, 2012 at 10:06:26AM +0100, Felipe Contreras wrote: I think you are the one that is not understanding what I'm saying. But I don't think it matters. This is what I'm saying; the current situation with 'git commit' is not OK, _both_ 'git commit' and 'git send-email' should change. Perhaps I am being dense, but this is the first time it became apparent to me that you are arguing for a change in git commit. Miscomunication then. When you mentioned 'it has always been the case that you can use git without setting user.*', I directed my comments at git in general, not git send-email. Indeed I would, but there's other people that would benefit from this patch. I'm sure I'm not the only person that doesn't have sendmail.from configured, but does have user.name/user.email, and is constantly typing enter. And the difference is that I'm _real_, the hypothetical user that sends patches with GIT_AUTHOR_NAME/EMAIL is not. I would be convinced otherwise if some evidence was presented that such a user is real though. Sadly we cannot poll the configuration of every user, nor expect them all to pay attention to this discussion on the list. So we cannot take the absence of comment from such users as evidence that they do not exist. And we cannot take it as evidence that these users do exist either. The absence of evidence simply means that... we don't have evidence. Instead we must use our judgement about what is being changed, and we tend to err on the side of keeping the status quo, since that is what the silent majority is busy _not_ complaining about. Yes, the keyword is *tend*; this wouldn't be first or the last time that a behavior change happens. We have to be careful about these changes, but we do them. We use the same judgement on the other side, too. Right now your evidence is 1 user wants this, 0 users do not. 1 is infinitely greater than 0. But we can guess that there are other people who would like the intent of your patch, but did not care enough or are not active enough on the list to write the patch themselves or comment on this thread. Yes, that would be an educated guess. IMO the fact that people use GIT_AUTHOR_ variables to send mail is not. There's many ways to achieve that: sendemail.from, --from, user configuration, $EMAIL, --compose and From:, etc. each and every one of them much more likely to be used than GIT_AUTHOR_. But I'm tired of arguing how extremely unlikely it is that such people don't exist. Lets agree to disagree. Either way it doesn't matter, because nobody is proposing a patch that would affect these hypothetical users. And to balance you need to *measure*, and that means taking into consideration who actually uses the features, if there's any. And it looks to me this is a feature nobody uses. You said measure and then it looks to me like. What did you measure? Did you consider systematic bias in your measurement, like the fact that people who are using the feature have no reason to come on the list and announce it? measure != scientific measurement. I used common sense, because that's the only tool available. GIT_AUTHOR is plumbing, not very well known, it's cumbersome (you need to export two variables), it can be easily confused with GIT_COMMITTER, which wouldn't work on this case. And there's plenty of tools that much simpler to use, starting with 'git send-email --from', which is so user friendly it's in the --help. There's absolutely no reason why anybody would want to use GIT_AUTHOR. But lets agree to disagree. But listen closely to what you said: I actually think it would make more sense to drop the prompt entirely and just die when the user has not given us a usable ident. Suppose somebody has a full name, and a fully qualified domain name, and he can receive mails to it directly. Such a user would not need a git configuration, and would not need $EMAIL, or anything. Currently 'git send-email' will throw 'Felipe Contreras feli...@felipec.org' which would actually work, but is not explicit. You are suggesting to break that use-case. You are introducing a regression. And this case is realistic, unlike the GIT_AUTHOR_NAME/EMAIL. Isn't it? Yes, dying would be a regression, in that you would have to configure your name via the environment and re-run rather than type it at the prompt. You raise a good point that for people who _could_ take the implicit default, hitting enter is working fine now, and we would lose that. I'd be fine with also just continuing to prompt in the implicit case. But that is a much smaller issue to me than having send-email fail to respect environment variables and silently use user.*, which is what started this whole discussion. And I agree it is worth considering as a regression we should avoid. It might be smaller, I don't think so. A hypothetical user that was relying on GIT_AUTHOR for
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
* ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on newer cygwin. Will merge to 'next'. (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu) (And thanks for maintaining git) Is everybody using cygwin happy with this? I managed to compile on a fresh installed cygwin, but failed to compile under 1.7.7, see below. Is there a way we can achieve to compile git both under old and new cygwin 1.7 ? Or is this not worth the effort? /Torsten CC compat/cygwin.o In file included from compat/../git-compat-util.h:90, from compat/cygwin.c:9: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: warning: #warning fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets In file included from /usr/include/sys/socket.h:16, from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr' /usr/include/cygwin/socket.h:41: error: redefinition of `struct sockaddr_storage' In file included from /usr/include/sys/socket.h:16, from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/cygwin/socket.h:59: error: redefinition of `struct linger' In file included from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/sys/socket.h:30: error: conflicting types for 'accept' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: error: previous declaration of 'accept' was here -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's cooking in git.git (Nov 2012, #03; Tue, 13)
-Original Message- From: Torsten Bögershausen Sent: Tuesday, November 13, 2012 3:45 PM * ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on newer cygwin. Will merge to 'next'. (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu) (And thanks for maintaining git) Is everybody using cygwin happy with this? I managed to compile on a fresh installed cygwin, but failed to compile under 1.7.7, see below. Is there a way we can achieve to compile git both under old and new cygwin 1.7 ? Or is this not worth the effort? Only supporting the new cygwin would make sense. You have to work hard at using older cygwin environments. I will give it a spin later today or tomorrow. -Jason smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
On Mon, Nov 12, 2012 at 9:47 AM, Junio C Hamano gits...@pobox.com wrote: Michael Haggerty mhag...@alum.mit.edu writes: The log message of the original commit (0454dd93bf) described the following scenario: a /home partition under which user home directories are automounted, and setting GIT_CEILING_DIRECTORIES=/home to avoid hitting /home/.git, /home/.git/objects, and /home/objects (which would attempt to automount those directories). I believe that this scenario would not be slowed down by my patches. How do you use GIT_CEILING_DIRECTORIES that the proposed changes cause a slowdown? Yeah, I was also wondering about that. David? I double-checked our configuration and all the parent directories of those listed in GIT_CEILING_DIRECTORIES are local, so our particular configuration would not have a performance hit. We do have multiple directories listed there. Some of them share a parent directory. I'm assuming the implementation is simple and does not try and avoid repeating the check when the parent dir is the same across multiple entries. In any case, it won't be a problem in practice based on my reading of the current code. Is there another way to accomplish this without the performance hit? Maybe something that can be solved with configuration? Without doing the symlink expansion there is no way for git to detect that GIT_CEILING_DIRECTORIES contains symlinks and is therefore ineffective. So the user has no warning about the misconfiguration (except that git runs slowly). On 10/29/2012 02:42 AM, Junio C Hamano wrote: Perhaps not canonicalize elements on the CEILING list ourselves? If we make it a user error to put symlinked alias in the variable, and document it clearly, wouldn't it suffice? There may be no other choice. (That, and fix the test suite in another way to tolerate a $PWD that involves symlinks.) -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [regression] Newer gits cannot clone any remote repos
On 13.11.12 19:55, Ramsay Jones wrote: Douglas Mencken wrote: *Any* git clone fails with: fatal: premature end of pack file, 106 bytes missing fatal: index-pack failed At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5 then, and it worked. Then I tried 1.7.12.2, but it fails the same way as 1.8.0. So I decided to git bisect. b8a2486f1524947f232f657e9f2ebf44e3e7a243 is the first bad commit ``index-pack: support multithreaded delta resolving'' This looks like the same problem I had on cygwin, which lead to commit c0f86547c (index-pack: Disable threading on cygwin, 26-06-2012). I didn't notice which platform you are on, but maybe you also have a thread-unsafe pread()? Could you try re-building git with the NO_THREAD_SAFE_PREAD build variable set? HTH. ATB, Ramsay Jones This is interesting. I had the same problem on a PowerPC (Old PowerBook G4 running Linux). Using NO_THREAD_SAFE_PREAD helped, thanks for the hint. (After recompiling without NO_THREAD_SAFE_PREAD I could clone from this machine again, so the problem is not really reproducable) Are there more people running PowerPC (on the server side) ? /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Chris Rorvick ch...@rorvick.com writes: Minor changes since from v2 set. Reposting primarily because I mucked up the Cc: list (again) and hoping to route feedback to the appropriate audience. This patch set can be divided into two sets: 1. Provide useful advice for rejected tag references. push: return reject reasons via a mask push: add advice for rejected tag reference Recommending a merge to resolve a rejected tag update seems nonsensical since the tag does not come along for the ride. These patches change the advice for rejected tags to suggest using push -f. Below, I take that you mean by tag reference everything under refs/tags/ (not limited to annotated tag objects, but also lightweight tags). Given that the second point below is to strongly discourage updating of existing any tag, it might be even better to advise *not* to push tags in the first place, instead of destructive push -f, no? 2. Require force when updating tag references, even on a fast-forward. push: flag updates push: flag updates that require force push: update remote tags only with force An email thread initiated by Angelo Borsotti did not come to a consensus on how push should behave with regard to tag references. I think the original motivation of allowing fast-forward updates to tags was for people who wanted to have today's recommended version tag that can float from day to day. I tend to think that was a misguided notion and it is better implemented with a tip of a branch (iow, I personally am OK with the change to forbid tag updates altogether, without --force). I think a key point is that you currently cannot be sure your push will not clobber a tag (lightweight or not) in the remote. Do not update, only add new may be a good feature, but at the same time I have this suspicion that its usefulness may not necessarily be limited to refs/tags/* hierarchy. I dunno. -- 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] update-index/diff-index: use core.preloadindex to improve performance
Am 13.11.2012 17:46, schrieb Junio C Hamano:
karsten.bl...@dcon.de writes:
If anything, fix your mailer probably is the policy you are
looking for, I think.
Well then...I've cloned myself @gmail, I hope this is better.
Just some provoking thoughts...(if I may):
RFC-5322 recommends wrapping lines at 78, and mail relays and gateways are
allowed to change message content according to the capabilities of the receiver
(RFC-5598). In essence, plaintext mail is completely unsuitable for
preformatted text such as source code.
On the other hand, git tries to solve the very problem of distributed source
code management, and consistency by strong sha-1 checksums is on the top of the
feature list.
It is somehow hard to believe that contributing to git itself should only be
possible using the most unreliable of protocols. Don't you trust your own
software?
-- 8 --
Subject: [PATCH] update-index/diff-index: use core.preloadindex to improve
performance
'update-index --refresh' and 'diff-index' (without --cached) don't honor
the core.preloadindex setting yet. Porcelain commands using these (such as
git [svn] rebase) suffer from this, especially on Windows.
Use read_cache_preload to improve performance.
Additionally, in builtin/diff.c, don't preload index status if we don't
access the working copy (--cached).
Results with msysgit on WebKit repo (2GB in 200k files):
| update-index | diff-index | rebase
+--++-
msysgit-v1.8.0 | 9.157s |10.536s | 42.791s
+ preloadindex | 9.157s |10.536s | 28.725s
+ this patch| 2.329s | 2.752s | 15.152s
+ fscache [1] | 0.731s | 1.171s | 8.877s
[1] https://github.com/kblees/git/tree/kb/fscache-v3
Thanks-to: Albert Krawczyk pro-lo...@optusnet.com.au
Signed-off-by: Karsten Blees bl...@dcon.de
---
Can also be pulled from:
https://github.com/kblees/git/tree/kb/update-diff-index-preload-upstream
More performance figures (for msysgit) can be found in this discussion:
https://github.com/pro-logic/git/commit/32c03dd8
builtin/diff-index.c | 8 ++--
builtin/diff.c | 12
builtin/update-index.c | 1 +
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/builtin/diff-index.c b/builtin/diff-index.c
index 2eb32bd..1c737f7 100644
--- a/builtin/diff-index.c
+++ b/builtin/diff-index.c
@@ -41,9 +41,13 @@ int cmd_diff_index(int argc, const char **argv, const char
*prefix)
if (rev.pending.nr != 1 ||
rev.max_count != -1 || rev.min_age != -1 || rev.max_age != -1)
usage(diff_cache_usage);
- if (!cached)
+ if (!cached) {
setup_work_tree();
- if (read_cache() 0) {
+ if (read_cache_preload(rev.diffopt.pathspec.raw) 0) {
+ perror(read_cache_preload);
+ return -1;
+ }
+ } else if (read_cache() 0) {
perror(read_cache);
return -1;
}
diff --git a/builtin/diff.c b/builtin/diff.c
index 9650be2..198b921 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -130,8 +130,6 @@ static int builtin_diff_index(struct rev_info *revs,
usage(builtin_diff_usage);
argv++; argc--;
}
- if (!cached)
- setup_work_tree();
/*
* Make sure there is one revision (i.e. pending object),
* and there is no revision filtering parameters.
@@ -140,8 +138,14 @@ static int builtin_diff_index(struct rev_info *revs,
revs-max_count != -1 || revs-min_age != -1 ||
revs-max_age != -1)
usage(builtin_diff_usage);
- if (read_cache_preload(revs-diffopt.pathspec.raw) 0) {
- perror(read_cache_preload);
+ if (!cached) {
+ setup_work_tree();
+ if (read_cache_preload(revs-diffopt.pathspec.raw) 0) {
+ perror(read_cache_preload);
+ return -1;
+ }
+ } else if (read_cache() 0) {
+ perror(read_cache);
return -1;
}
return run_diff_index(revs, cached);
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 74986bf..ada1dff 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -593,6 +593,7 @@ struct refresh_params {
static int refresh(struct refresh_params *o, unsigned int flag)
{
setup_work_tree();
+ read_cache_preload(NULL);
*o-has_errors |= refresh_cache(o-flags | flag);
return 0;
}
--
1.8.0.msysgit.0.3.g7d9d98c
--
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: [regression] Newer gits cannot clone any remote repos
Torsten Bögershausen tbo...@web.de writes: Are there more people running PowerPC (on the server side) ? I cannot reproduce the problem (on openSUSE 12.2). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bug? git format-patch -M -D then git am fails
If a file is deleted with git rm and a patch is then generated with git format-patch -M - -- 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
bug? git format-patch -M -D then git am fails
(Sorry about the partial message. evolution and ctrl-enter sends, grumble...) If a file is deleted with git rm and a patch is then generated with git format-patch -M -D git am is unable to apply the resultant patch. Is this working as designed? -- 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: bug? git format-patch -M -D then git am fails
Joe Perches j...@perches.com writes: (Sorry about the partial message. evolution and ctrl-enter sends, grumble...) If a file is deleted with git rm and a patch is then generated with git format-patch -M -D git am is unable to apply the resultant patch. Is this working as designed? I would say it is broken as designed and it is even documented. Please run git format-patch --help | less and then type /--irreversible-delete to find: The resulting patch is not meant to be applied with patch nor git apply; this is solely for people who want to just concentrate on reviewing the text after the change. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Jeff King p...@peff.net writes: What's cooking in git.git (Nov 2012, #03; Tue, 13) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. This is my final what's cooking as interim maintainer. I didn't graduate anything to master, but I updated my plans for each topic to give Junio an idea of where I was. You can find the changes described here in the integration branches of my repository at: git://github.com/peff/git.git Until Junio returns, kernel.org and the other usual places will not be updated. And now the usual places have been updated with the same tips of integration branches (the broken-out https://github.com/gitster/git repository, too). -- 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: bug? git format-patch -M -D then git am fails
On Tue, 2012-11-13 at 14:55 -0800, Junio C Hamano wrote: Joe Perches j...@perches.com writes: (Sorry about the partial message. evolution and ctrl-enter sends, grumble...) If a file is deleted with git rm and a patch is then generated with git format-patch -M -D git am is unable to apply the resultant patch. Is this working as designed? I would say it is broken as designed and it is even documented. Please run git format-patch --help | less and then type /--irreversible-delete to find: The resulting patch is not meant to be applied with patch nor git apply; this is solely for people who want to just concentrate on reviewing the text after the change. yeah, it's just that not using -D can result in some unfortunately large patches being sent to mailing lists. I don't believe that reversibility is a really useful aspect of deletion patches when there are known git repositories involved. cheers, Joe -- 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] pickaxe: use textconv for -S counting
Jeff King p...@peff.net writes:
We currently just look at raw blob data when using -S to
pickaxe. This is mostly historical, as pickaxe predates the
textconv feature. If the user has bothered to define a
textconv filter, it is more likely that their search string will be
on the textconv output, as that is what they will see in the
diff (and we do not even provide a mechanism for them to
search for binary needles that contain NUL characters).
Oookay, I suppose...
static int has_changes(struct diff_filepair *p, struct diff_options *o,
regex_t *regexp, kwset_t kws)
{
+ struct userdiff_driver *textconv_one = get_textconv(p-one);
+ struct userdiff_driver *textconv_two = get_textconv(p-two);
+ mmfile_t mf1, mf2;
+ int ret;
+
if (!o-pickaxe[0])
return 0;
- if (!DIFF_FILE_VALID(p-one)) {
- if (!DIFF_FILE_VALID(p-two))
- return 0; /* ignore unmerged */
What happened to this part that avoids showing nonsense for unmerged
paths?
+ /*
+ * If we have an unmodified pair, we know that the count will be the
+ * same and don't even have to load the blobs. Unless textconv is in
+ * play, _and_ we are using two different textconv filters (e.g.,
+ * because a pair is an exact rename with different textconv attributes
+ * for each side, which might generate different content).
+ */
+ if (textconv_one == textconv_two diff_unmodified_pair(p))
+ return 0;
I am not sure about this part that cares about the textconv.
Wouldn't the normal git diff A B skip the filepair that are
unmodified in the first place at the object name level without even
looking at the contents (see e.g. diff_flush_patch())?
Shouldn't this part of the code emulating that behaviour no matter
what textconv filter(s) are configured for these paths?
--
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: checkout from neighbour branch undeletes a path?
Peter Vereshagin pe...@vereshagin.org writes: $ rm -r pathdir $ git checkout branch00 pathdir $ find pathdir/ pathdir/ pathdir/file00.txt pathdir/file01.txt $ Hasn't this been fixed at 0a1283b (checkout $tree $path: do not clobber local changes in $path not in $tree, 2011-09-30)? Are you using 1.7.7.1 or newer? If not, please upgrade. -- 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: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
Hi,
On Tue, Nov 13, 2012 at 03:12:44PM -0500, Marc Khouzam wrote:
+if [ -n $1 ] ; then
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
Where does the second argument come from? Below you run this script
as '${__git_tcsh_completion_script} ${COMMAND_LINE}', i.e. $2 is
never set. Am I missing something?
This second argument is optional and, if present, will be put in
$COMP_CWORD. If not present, $COMP_CWORD must be computed
from $1. Also see comment above _git_complete_with_output ().
tcsh does not provide me with this information, so I cannot make use of it.
However, I thought it would be more future-proof to allow it for other shells
which may have that information.
It is not necessary for tcsh, so I can remove if you prefer?
I see. I read those comments and understood what it is about. I was
just surprised that the code is there to make use of it, yet it's not
specified when invoking that function.
Since it's a trivial piece of code, I would say let's keep it. Could
you please add a sentence about it (that it's for possible future
users and it's not used at the moment) to the commit message for
future reference?
+complete git 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
+complete gitk 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
Is the 'sort | uniq' really necessary? After the completion function
returns Bash automatically sorts the elements in COMPREPLY and removes
any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
completion.
On my machine, tcsh does not remove duplicates. It does sort the results
but that is done after I've run 'uniq', which is too late. I'm not
happy about this
either, but the other option is to improve git-completion.bash to
avoid duplicates,
which seemed less justified.
Ok. Then keep it for the time being, and we'll see what we can do to
avoid those duplicates.
Does the git completion script returns any duplicates at all?
It does. 'help' is returned twice for example.
Right. Now that you mentioned it, I remember I noticed it a while
ago, too. I even wrote a patch to fix it, but not sure what became of
it. Will try to dig it up.
Also, when completing 'git checkout ' in the git repo, I can see multiple
'todo' branches, as well as 'master', 'pu', 'next', etc.
You can actually try it without tcsh by running my proposed version of
git-completion.bash like this:
cd git/contrib/completion
bash git-completion.bash git checkout | sort | uniq --repeated
Interesting, I can't reproduce. Are the duplicates also there, if you
start a bash, source git-completion.bash, and run __git_refs ?
--
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: [PATCHv3 3/4] git-status: show short sequencer state
Phil Hord wrote: Junio C Hamano wrote: Phil Hord ho...@cisco.com writes: State token strings which may be emitted and their meanings: merge a merge is in progress am an am is in progress am-is-emptythe am patch is empty rebase a rebase is in progress rebase-interactive an interactive rebase is in progress cherry-picka cherry-pick is in progress bisect a bisect is in progress conflicted there are unresolved conflicts commit-pending a commit operation is waiting to be completed splitting interactive rebase, commit is being split I also considered adding these tokens, but I decided it was not appropriate since these changes are not sequencer-related. But it is possible I am being too short-sighted or have chosen the switch name poorly. changed-index Changes exist in the index changed-files Changes exist in the working directory untracked New files exist in the working directory I tend to agree; unlike all the normal output from status -s that are per-file, the above are the overall states of the working tree. It is just that most of the overall states look as if they are dominated by sequencer states, but that is only because you chose to call states related to things like am and bisect that are not sequencer states as such. It probably should be called the tree state, working tree state, or somesuch. I think you are agreeing that I chose the switch name poorly, right? Do you think '--tree-state' is an acceptable switch or do you have other suggestions? I've been calling these 'tokens' myself. A token is a word-or-phrase I can parse easily with the default $IFS, for simpler script handling. I'm happy to make that official and use --tokens and -T, but I suspect a more appropriate name is available. Phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
On Sun, Nov 11, 2012 at 11:08 PM, Chris Rorvick ch...@rorvick.com wrote: Minor changes since from v2 set. . An email thread initiated by Angelo Borsotti did not come to a consensus on how push should behave with regard to tag references. Minor Nit: Without the link to gmane it is an exercise left to the reviewer to find that you're talking about this thread: http://thread.gmane.org/gmane.comp.version-control.git/208354 Cheers. -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
Hi,
I've got two more comments.
On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
@@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
if [ Cygwin = $(uname -o 2/dev/null) ]; then
__git_complete git.exe __git_main
fi
+
+# Method that will output the result of the completion done by
+# the bash completion script, so that it can be re-used in another
+# context than the bash complete command.
+# It accepts 1 to 2 arguments:
+# 1: The command-line to complete
+# 2: The index of the word within argument #1 in which the cursor is
+#located (optional). If parameter 2 is not provided, it will be
+#determined as best possible using parameter 1.
+_git_complete_with_output ()
We differentiate between _git_whatever() and __git_whatever()
functions. The former performs completion for the 'whatever' git
command/alias, the latter is a completion helper function. This
is a helper function, so it should begin with double underscores.
+{
+ # Set COMP_WORDS to the command-line as bash would.
+ COMP_WORDS=($1)
+
+ # Set COMP_CWORD to the cursor location as bash would.
+ if [ -n $2 ]; then
A while ago the completion script was made 'set -u'-clean. (If 'set
-u' is enabled, then it's an error to access undefined variables).
I'm not sure how many people are out there who'd use this script for
tcsh while having 'set -u' in their profile... probably not that
many. Still, I think it would be great to keep it up.
Here $2 would be undefined, so accessingit it would cause an error
under those semantincs. Please use ${2-} instead (use empty string
when undefined).
+if [ -n $1 ] ; then
Same here.
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
And here.
Thanks
Gábor
--
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] Add tcsh-completion support to contrib by using git-completion.bash
On Tue, Nov 13, 2012 at 07:31:45PM +0100, Felipe Contreras wrote:
On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam marc.khou...@gmail.com wrote:
+ # Call _git() or _gitk() of the bash script, based on the first
+ # element of the command-line
+ _${COMP_WORDS[0]}
You might want to use __${COMP_WORDS[0]}_main instead.
That wouldn't work. __git_main() doesn't set up the
command-line-specific variables, but the wrapper around it does.
+# Make the script executable if it is not
+if ( ! -x ${__git_tcsh_completion_script} ) then
+ chmod u+x ${__git_tcsh_completion_script}
+endif
Why not just source it?
The goal is to re-use a Bash script to do completion in tcsh. They
are two different breeds, tcsh doesn't grok bash. So sourcing the
completion script is not an option, but we can still run it via Bash
and use it's results.
--
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: remove 'help' duplicate from porcelain commands
The list of all git commands is computed from the output of 'git help
-a', which already includes 'help', so there is no need to explicitly
add it once more when computing the list of porcelain commands.
Note that 'help' wasn't actually offered twice because of this,
because Bash filters duplicates from possible completion words.
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
Does the git completion script returns any duplicates at all?
It does. 'help' is returned twice for example.
Right. Now that you mentioned it, I remember I noticed it a while
ago, too. I even wrote a patch to fix it, but not sure what became of
it. Will try to dig it up.
Here it is. It turns out I wrote it in May this year, but according to
gmane and my mailbox never sent it out.
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc0657a2..b7b1a834 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -585,7 +585,7 @@ __git_list_porcelain_commands ()
{
local i IFS= $'\n'
__git_compute_all_commands
- for i in help $__git_all_commands
+ for i in $__git_all_commands
do
case $i in
*--*) : helper pattern;;
--
1.8.0.128.g441b4b3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 11/13/2012 03:45 PM, Torsten Bögershausen wrote: * ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on newer cygwin. Will merge to 'next'. (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu) (And thanks for maintaining git) Is everybody using cygwin happy with this? I managed to compile on a fresh installed cygwin, but failed to compile under 1.7.7, see below. Is there a way we can achieve to compile git both under old and new cygwin 1.7 ? Or is this not worth the effort? /Torsten I found no version info defined that could be used to automatically switch between the old and current headers. You can always make V15_MINGW_HEADERS=1 ... to force using the old set if you do not wish to update your installation. Mark -- 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: Bug? Subtree merge seems to choke on trailing slashes.
Do I have the right list for bug reports? Apologies if not. On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor oconnor...@gmail.com wrote: I'm summarizing from here: http://stackoverflow.com/questions/5904256/git-subtree-merge-into-a-deeply-nested-subdirectory Quick repro: 1) I do an initial subtree merge in what I think is the standard way (http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html). My prefix is simply test/. 2) I try to merge more upstream changes on top of that with the following command: git merge --strategy-option=subtree='test/' $upstream_stuff 3) Git fails with an obscure error: fatal: entry not found in tree daf4d0f0a20b8b6ec007be9fcafeac84a6eba4f0 If I remove the trailing slash from the command in step 2, it works just fine: git merge --strategy-option=subtree='test' $upstream_stuff Note in the error message above, there's a double space after entry. Is it looking for a tree with an empty name? Did my trailing slash imply a directory named empty-string? Thanks for your help. -- Jack O'Connor -- 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
