Re: [PATCH] t/t5400-send-pack: Use POSIX options to cp for portability
Junio C Hamano wrote: Junio C Hamano writes: Ben Walton writes: Avoid a GNU-ism in the cp options used by t5400-send-pack. Change -a to -pR. Signed-off-by: Ben Walton --- Thanks, but is "-p" essential for this test to pass, or can we get away with just "-R"? Besides, when you spot a potential problem, please ask "git grep" to catch them all. $ git grep "cp -a" t/ t/t5400-send-pack.sh: cp -a parent child && t/t5550-http-fetch.sh: cp -a .git"$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && t/t5800-remote-helpers.sh: cp -a server server2 && There's 2 more places in Documentation/git-tutorial.txt. There it looks like we'd want to use 'cp -pR' instead Bye, Jojo -- 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 8/8] Support "**" wildcard in .gitignore and .gitattributes
I like how this series is going and it's going to be a nice new feature.
Some comments...
It would be helpful if you would use
--subject-prefix='PATCH v3'
etc. to help spectators keep track of the different versions of your
patch series.
On 10/09/2012 05:09 AM, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/gitignore.txt| 19 +++
> attr.c | 4 +++-
> dir.c | 4 +++-
> t/t0003-attributes.sh | 38
> ++
> t/t3001-ls-files-others-exclude.sh | 19 +++
> 5 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index 96639e0..5a9c9f7 100644
> --- a/Documentation/gitignore.txt
> +++ b/Documentation/gitignore.txt
> @@ -104,6 +104,25 @@ PATTERN FORMAT
> For example, "/{asterisk}.c" matches "cat-file.c" but not
> "mozilla-sha1/sha1.c".
>
> +Two consecutive asterisks ("`**`") in patterns matched against
> +full pathname may have special meaning:
> +
> + - A leading "`**`" followed by a slash means match in all
> + directories. For example, "`**/foo`" matches file or directory
> + "`foo`" anywhere, the same as pattern "`foo`". "**/foo/bar"
> + matches file or directory "`bar`" anywhere that is directly
> + under directory "`foo`".
> +
> + - A trailing "/**" matches everything inside. For example,
> + "abc/**" is equivalent to "`/abc/`".
It seems odd that you add a leading slash in this example. I assume
that is because of the rule that a pattern containing a slash is
considered anchored at the current directory. But I find it confusing
because the addition of the leading slash is not part of the rule you
are trying to illustrate here, and is therefore a distraction. I
suggest that you write either
- A trailing "/**" matches everything inside. For example,
"/abc/**" is equivalent to "`/abc/`".
or
- A trailing "/**" matches everything inside. For example,
"abc/**" is equivalent to "`abc/`" (which is also equivalent
to "`/abc/`").
> +
> + - A slash followed by two consecutive asterisks then a slash
> + matches zero or more directories. For example, "`a/**/b`"
> + matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on.
> +
> + - Consecutive asterisks otherwise are treated like normal
> + asterisk wildcards.
> +
I don't like the last rule. (1) This construct is superfluous; why
wouldn't the user just use a single asterisk? (2) Allowing this
construct means that it could appear in .gitignore files, creating
unnecessary confusion: extrapolating from the other meanings of "**"
users would expect that it would somehow match slashes. (3) It is
conceivable (though admittedly unlikely) that we might want to assign a
distinct meaning to this construct in the future, and accepting it now
as a different way to spell "*" would prevent such a change.
Perhaps this rule was intended for backwards compatibility?
I think it would be preferable to say that other uses of consecutive
asterisks are undefined, and probably make them trigger a warning.
> NOTES
> -
>
> diff --git a/attr.c b/attr.c
> index 887a9ae..e85e5ed 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -12,6 +12,7 @@
> #include "exec_cmd.h"
> #include "attr.h"
> #include "dir.h"
> +#include "wildmatch.h"
>
> const char git_attr__true[] = "(builtin)true";
> const char git_attr__false[] = "\0(builtin)false";
> @@ -666,7 +667,8 @@ static int path_matches(const char *pathname, int pathlen,
> return 0;
> if (baselen != 0)
> baselen++;
> - return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
> + return wildmatch(pattern, pathname + baselen,
> + ignore_case ? FNM_CASEFOLD : 0);
> }
>
> static int macroexpand_one(int attr_nr, int rem);
> diff --git a/dir.c b/dir.c
> index 4868339..dc721c0 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -8,6 +8,7 @@
> #include "cache.h"
> #include "dir.h"
> #include "refs.h"
> +#include "wildmatch.h"
>
> struct path_simplify {
> int len;
> @@ -575,7 +576,8 @@ int excluded_from_list(const char *pathname,
> namelen -= prefix;
> }
>
> - if (!namelen || !fnmatch_icase(exclude, name, FNM_PATHNAME))
> + if (!namelen ||
> + wildmatch(exclude, name, ignore_case ? FNM_CASEFOLD : 0))
> return to_exclude;
> }
> return -1; /* undecided */
> diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
> index febc45c..67a5694 100755
> --- a/t/t0003-attributes.sh
> +++ b/t/t0003-attributes.sh
> @@ -232,4 +232,42 @@ test_expect_success 'bare repository: test
> info/attributes' '
> attr_check subdir/a/i unspecified
> '
>
> +test_expect_success '"**" test' '
> + cd .. &&
> + echo "**/f foo=bar" >.gitattributes &&
> + cat <<\EOF >expect
[PATCH/RFC] svn test: escape peg revision separator using empty peg rev
This test script uses "svn cp" to create a branch with an @-sign in
its name:
svn cp "pr ject/trunk" "pr ject/branches/not-a@{0}reflog"
That sets up for later tests that fetch the branch and check that git
svn mangles the refname appropriately.
Unfortunately, modern svn versions interpret path arguments with an
@-sign as an example of path@revision syntax (which pegs a path to a
particular revision) and truncate the path or error out with message
"svn: E205000: Syntax error parsing peg revision '{0}reflog'".
When using subversion 1.6.x, escaping the @ sign as %40 avoids trouble
(see 08fd28bb, 2010-07-08). Newer versions are stricter:
$ svn cp "$repo/pr ject/trunk" "$repo/pr ject/branches/not-a%40{reflog}"
svn: E205000: Syntax error parsing peg revision '%7B0%7Dreflog'
The recommended method for escaping a literal @ sign in a path passed
to subversion is to add an empty peg revision at the end of the path
("branches/not-a@{0}reflog@"). Do that.
Pre-1.6.12 versions of Subversion probably treat the trailing @ as
another literal @-sign (svn issue 3651). Luckily ever since
v1.8.0-rc0~155^2~7 (t9118: workaround inconsistency between SVN
versions, 2012-07-28) the test can survive that.
Tested with Debian Subversion 1.6.12dfsg-6 and 1.7.5-1 and r1395837
of Subversion trunk (1.8.x).
Signed-off-by: Jonathan Nieder
---
Michael G Schwern wrote:
> On 2012.7.28 7:16 AM, Jonathan Nieder wrote:
>> Michael G. Schwern wrote:
>>> - git rev-parse "refs/remotes/not-a%40{0}reflog"
>>> + git rev-parse "refs/remotes/$non_reflog"
>>
>> Doesn't this defeat the point of the testcase (checking that git-svn
>> is able to avoid creating git refs containing @{, following the rules
>> from git-check-ref-format(1))?
>
> Unless I messed up, entirely possible as I'm not a shell programmer, the test
> is still useful for testing SVN 1.6. Under SVN 1.6 $non_reflog should be
> 'not-a%40{0}reflog' as before.
Here's a patch to make the test useful again for SVN 1.7. Sensible?
t/t9118-git-svn-funky-branch-names.sh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9118-git-svn-funky-branch-names.sh
b/t/t9118-git-svn-funky-branch-names.sh
index 193d3cab..15f93b4c 100755
--- a/t/t9118-git-svn-funky-branch-names.sh
+++ b/t/t9118-git-svn-funky-branch-names.sh
@@ -28,7 +28,7 @@ test_expect_success 'setup svnrepo' '
svn_cmd cp -m "trailing .lock" "$svnrepo/pr ject/trunk" \
"$svnrepo/pr ject/branches/trailing_dotlock.lock" &&
svn_cmd cp -m "reflog" "$svnrepo/pr ject/trunk" \
- "$svnrepo/pr ject/branches/not-a%40{0}reflog" &&
+ "$svnrepo/pr ject/branches/not-a@{0}reflog@" &&
start_httpd
'
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
Running 'git grep needle origin/master' on Windows gives numerous warnings of the kind warning: unable to access 'origin/master:Documentation/.gitattributes': Invalid argument It is worrysome that it is attempted to access a file whose name is prefixed by a revision. -- 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: git checkout error
Angelo Borsotti writes: > If they are specified after -b, the command seems to behave as if -b > was not specified, e.g.: > > $ git checkout -b --no-track topic remotes/origin/master -b requires an argument , which you specify as --no-track here. is topic, and the rest is interpreted as . > fatal: git checkout: updating paths is incompatible with switching branches. This error is detected before validating . > while if they are specified before -b the command behaves properly, e.g. > > $ git checkout --no-track -b topic remotes/origin/master > Switched to a new branch 'topic' You can also specify --no-track after -b (and its argument): $ git checkout -b topic --no-track remotes/origin/master 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
gitweb bug: Existence if hidden repositories is leaked
Hi list, I am using gitweb, git-daemon and gitolite on my Debian Squeeze server. I have some repositories however that I do not want to be available to the public (currently, that is gitolite-admin only). Those repositories do not have a "git-daemon-export-ok" file, and the gitweb config contains # path to git projects (.git) $projectroot = "/home/git/repositories"; # only show repos which allow daemon access $export_ok = "git-daemon-export-ok"; I am also using pathinfo to get prettier URLs. However, if I now try to access gitolite-admin.git in the browser, I get "404 Project Not Found". If I try to access some repository which dos not actually exist, I am redirected to the project index. This way, the existence of hidden repositories is disclosed. The problem is in the function evaluate_path_info which uses check_head_link to find out which part of the URL is the project. Replacing this by check_export_ok fixes the problem. Kind regards, Ralf PS: Please keep me in CC, I am not subscribed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
On Tue, Oct 9, 2012 at 4:03 PM, Johannes Sixt wrote: > Running 'git grep needle origin/master' on Windows gives numerous warnings > of the kind > > warning: unable to access 'origin/master:Documentation/.gitattributes': > Invalid argument strace confirms it. Stack trace #0 read_attr_from_file (path=0x820e818 "HEAD:Documentation/.gitattributes", macro_ok=0) at attr.c:351 #1 0x080d378d in read_attr (path=0x820e818 "HEAD:Documentation/.gitattributes", macro_ok=0) at attr.c:436 #2 0x080d3bf1 in prepare_attr_stack (path=0x820e7f0 "HEAD:Documentation/.gitattributes") at attr.c:630 #3 0x080d3f68 in collect_all_attrs (path=0x820e7f0 "HEAD:Documentation/.gitattributes") at attr.c:747 #4 0x080d3ffd in git_check_attr (path=0x820e7f0 "HEAD:Documentation/.gitattributes", num=1, check=0xbfffd848) at attr.c:761 #5 0x0815e736 in userdiff_find_by_path (path=0x820e7f0 "HEAD:Documentation/.gitattributes") at userdiff.c:278 #6 0x081058ca in grep_source_load_driver (gs=0xbfffd978) at grep.c:1504 #7 0x08105907 in grep_source_is_binary (gs=0xbfffd978) at grep.c:1512 #8 0x08104eaa in grep_source_1 (opt=0xbfffe304, gs=0xbfffd978, collect_hits=0) at grep.c:1180 Never touched userdiff.c before. Anybody? -- 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: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev
Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41:
> This test script uses "svn cp" to create a branch with an @-sign in
> its name:
>
> svn cp "pr ject/trunk" "pr ject/branches/not-a@{0}reflog"
>
> That sets up for later tests that fetch the branch and check that git
> svn mangles the refname appropriately.
>
> Unfortunately, modern svn versions interpret path arguments with an
> @-sign as an example of path@revision syntax (which pegs a path to a
> particular revision) and truncate the path or error out with message
> "svn: E205000: Syntax error parsing peg revision '{0}reflog'".
>
> When using subversion 1.6.x, escaping the @ sign as %40 avoids trouble
> (see 08fd28bb, 2010-07-08). Newer versions are stricter:
>
> $ svn cp "$repo/pr ject/trunk" "$repo/pr ject/branches/not-a%40{reflog}"
> svn: E205000: Syntax error parsing peg revision '%7B0%7Dreflog'
>
> The recommended method for escaping a literal @ sign in a path passed
> to subversion is to add an empty peg revision at the end of the path
> ("branches/not-a@{0}reflog@"). Do that.
>
> Pre-1.6.12 versions of Subversion probably treat the trailing @ as
> another literal @-sign (svn issue 3651). Luckily ever since
> v1.8.0-rc0~155^2~7 (t9118: workaround inconsistency between SVN
> versions, 2012-07-28) the test can survive that.
>
> Tested with Debian Subversion 1.6.12dfsg-6 and 1.7.5-1 and r1395837
> of Subversion trunk (1.8.x).
>
> Signed-off-by: Jonathan Nieder
Tested with Subversion 1.6.18.
> ---
> Michael G Schwern wrote:
>> On 2012.7.28 7:16 AM, Jonathan Nieder wrote:
>>> Michael G. Schwern wrote:
>
- git rev-parse "refs/remotes/not-a%40{0}reflog"
+ git rev-parse "refs/remotes/$non_reflog"
>>>
>>> Doesn't this defeat the point of the testcase (checking that git-svn
>>> is able to avoid creating git refs containing @{, following the rules
>>> from git-check-ref-format(1))?
>>
>> Unless I messed up, entirely possible as I'm not a shell programmer, the test
>> is still useful for testing SVN 1.6. Under SVN 1.6 $non_reflog should be
>> 'not-a%40{0}reflog' as before.
>
> Here's a patch to make the test useful again for SVN 1.7. Sensible?
>
> t/t9118-git-svn-funky-branch-names.sh |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t9118-git-svn-funky-branch-names.sh
> b/t/t9118-git-svn-funky-branch-names.sh
> index 193d3cab..15f93b4c 100755
> --- a/t/t9118-git-svn-funky-branch-names.sh
> +++ b/t/t9118-git-svn-funky-branch-names.sh
> @@ -28,7 +28,7 @@ test_expect_success 'setup svnrepo' '
> svn_cmd cp -m "trailing .lock" "$svnrepo/pr ject/trunk" \
> "$svnrepo/pr ject/branches/trailing_dotlock.lock" &&
> svn_cmd cp -m "reflog" "$svnrepo/pr ject/trunk" \
> - "$svnrepo/pr ject/branches/not-a%40{0}reflog" &&
> + "$svnrepo/pr ject/branches/not-a@{0}reflog@" &&
> start_httpd
> '
I haven't checked other svn versions but this approach looks perfectly
sensible. It makes us test branch names which can't even be created
easily with current svn. Does svn really deserve this much attention? ;)
Seriously, our tests prepare us well for an svn remote helper...
--
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 v2] git svn: work around SVN 1.7 mishandling of svn:special changes
Subversion represents symlinks as ordinary files with content starting
with "link " and the svn:special property set to "*". Thus a file can
switch between being a symlink and a non-symlink simply by toggling
its svn:special property, and new checkouts will automatically write a
file of the appropriate type. Likewise, in subversion 1.6 and older,
running "svn update" would notice changes in filetype and update the
working copy appropriately.
Starting in subversion 1.7 (issue 4091), changes to the svn:special
property trip an assertion instead:
$ svn up svn-tree
Updating 'svn-tree':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \
line 1583: assertion failed (action == svn_wc_conflict_action_edit \
|| action == svn_wc_conflict_action_delete || action == \
svn_wc_conflict_action_replace)
Revisions prepared with ordinary svn commands ("svn add" and not "svn
propset") don't trip this because they represent these filetype
changes using a replace operation, which is approximately equivalent
to removal followed by adding a new file and works fine. Follow suit.
Noticed using t9100. After this change, git-svn's file-to-symlink
changes are sent in a format that modern "svn update" can handle and
tests t9100.11-13 pass again.
Signed-off-by: Jonathan Nieder
---
Jonathan Nieder wrote:
> Revisions prepared with ordinary svn commands ("svn add" and not "svn
> propset") don't trip this because they represent filetype changes
> using a replace operation [...]
>Perhaps "git
> svn" should mimic that,
... and here's what that looks like. I like this more than ignoring
the problem in tests, and I suppose something like this is necessary
regardless of how quickly issue 4091 is fixed for compatibility with
the broken versions of svn.
It would be nice if the patch could be more concise, though. What do
you think?
git-svn.perl | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/git-svn.perl b/git-svn.perl
index 9d57aa0c..40ccdd50 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5439,7 +5439,30 @@ sub M {
$self->close_file($fbat,undef,$self->{pool});
}
-sub T { shift->M(@_) }
+sub T {
+ my ($self, $m, $deletions) = @_;
+
+ # Work around subversion issue 4091: toggling the "is a
+ # symlink" property requires removing and re-adding a
+ # file or else "svn up" on affected clients trips an
+ # assertion and aborts.
+ if (($m->{mode_b} =~ /^120/ && $m->{mode_a} !~ /^120/) ||
+ ($m->{mode_b} !~ /^120/ && $m->{mode_a} =~ /^120/)) {
+ $self->D({
+ mode_a => $m->{mode_a}, mode_b => '00',
+ sha1_a => $m->{sha1_a}, sha1_b => '0' x 40,
+ chg => 'D', file_b => $m->{file_b}
+ });
+ $self->A({
+ mode_a => '00', mode_b => $m->{mode_b},
+ sha1_a => '0' x 40, sha1_b => $m->{sha1_b},
+ chg => 'A', file_b => $m->{file_b}
+ });
+ return;
+ }
+
+ $self->M($m, $deletions);
+}
sub change_file_prop {
my ($self, $fbat, $pname, $pval) = @_;
--
1.7.10.4
--
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/RFC] svn test: escape peg revision separator using empty peg rev
Michael J Gruber wrote: > Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41: >> Signed-off-by: Jonathan Nieder > > Tested with Subversion 1.6.18. [...] > I haven't checked other svn versions but this approach looks perfectly > sensible. It makes us test branch names which can't even be created > easily with current svn. Does svn really deserve this much attention? ;) Thanks for the quick and thorough feedback. I'm glad to hear it seems sane. ;-) > Seriously, our tests prepare us well for an svn remote helper... That might be a good reason to make a mock implementation of the existing git-svn interface on top of git-remote-svn. Sounds fun but hard. Ciao, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
On Tue, Oct 09, 2012 at 04:38:32PM +0700, Nguyen Thai Ngoc Duy wrote:
> #5 0x0815e736 in userdiff_find_by_path (path=0x820e7f0
> "HEAD:Documentation/.gitattributes") at userdiff.c:278
> #6 0x081058ca in grep_source_load_driver (gs=0xbfffd978) at grep.c:1504
A bandage patch may look like this. But it does not solve the real
problem:
- we should be able to look up in-tree .gitattributes, not just
ignore like this patch does
- gs->name seems to be prepared for human consumption, not for
accessing files. grep_file() with opt->relative is true can put
quotes in gs->name, for example.
I feel like we should make this function a callback and let git-grep
deal with driver loading itself.
-- 8< --
diff --git a/grep.c b/grep.c
index edc7776..c5ed067 100644
--- a/grep.c
+++ b/grep.c
@@ -1501,7 +1501,8 @@ void grep_source_load_driver(struct grep_source *gs)
return;
grep_attr_lock();
- gs->driver = userdiff_find_by_path(gs->name);
+ if (gs->type == GREP_SOURCE_FILE)
+ gs->driver = userdiff_find_by_path(gs->name);
if (!gs->driver)
gs->driver = userdiff_find_by_name("default");
grep_attr_unlock();
-- 8< --
--
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: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
Hi, On Mon, Oct 8, 2012 at 3:19 PM, Elia Pinto wrote: > Ok. I have found. For me this is not a problem any more these days. > Was fixed in glibc 2.8.90-9 2008 > > * Wed Jul 16 2008 Jakub Jelinek 2.8.90-9 > - update from trunk > - fix unbuffered vfprintf if writing to the stream fails (#455360) > - remove useless "malloc: using debugging hooks" message (#455355) > - nscd fixes > (from glibc rpm changelog) > > This is the bugzilla filled and closed > https://bugzilla.redhat.com/show_bug.cgi?id=455355 > > Ramsay, what version of glibc you have and in what distro? thanks I have the same problem on a RHEL 5.3 (2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux) with glibc-2.5-34. Best, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
On Tue, Oct 09, 2012 at 07:01:44PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Oct 09, 2012 at 04:38:32PM +0700, Nguyen Thai Ngoc Duy wrote:
> > #5 0x0815e736 in userdiff_find_by_path (path=0x820e7f0
> > "HEAD:Documentation/.gitattributes") at userdiff.c:278
> > #6 0x081058ca in grep_source_load_driver (gs=0xbfffd978) at grep.c:1504
>
> A bandage patch may look like this. But it does not solve the real
> problem:
>
> - we should be able to look up in-tree .gitattributes, not just
>ignore like this patch does
>
> - gs->name seems to be prepared for human consumption, not for
>accessing files. grep_file() with opt->relative is true can put
>quotes in gs->name, for example.
Right. For the second, you would probably want gs->identifier in the
case of GREP_SOURCE_FILE. But that identifier information is not
available at all for GREP_SOURCE_SHA1, which is what is breaking the
first point.
> I feel like we should make this function a callback and let git-grep
> deal with driver loading itself.
I think we just need to have callers of grep_source_init provide us with
the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is
where the information is lost.
Like this incomplete and untested patch, which should fix the quoting
problem for GREP_SOURCE_FILE, but leave the sha1 bits broken (see the
in-code comment). I'm traveling this week, so I doubt I'll have time to
look for a few more days. If you want to work on it, please do.
diff --git a/builtin/grep.c b/builtin/grep.c
index 82530a6..be602dd 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -86,7 +86,7 @@ static void add_work(struct grep_opt *opt, enum
grep_source_type type,
static int skip_first_line;
static void add_work(struct grep_opt *opt, enum grep_source_type type,
-const char *name, const void *id)
+const char *name, const char *path, const void *id)
{
grep_lock();
@@ -94,7 +94,7 @@ static void add_work(struct grep_opt *opt, enum
grep_source_type type,
pthread_cond_wait(&cond_write, &grep_mutex);
}
- grep_source_init(&todo[todo_end].source, type, name, id);
+ grep_source_init(&todo[todo_end].source, type, name, path, id);
if (opt->binary != GREP_BINARY_TEXT)
grep_source_load_driver(&todo[todo_end].source);
todo[todo_end].done = 0;
@@ -378,14 +378,21 @@ static int grep_sha1(struct grep_opt *opt, const unsigned
char *sha1,
if (opt->relative && opt->prefix_length) {
quote_path_relative(filename + tree_name_len, -1, &pathbuf,
opt->prefix);
+ /* XXX Why do we insert here instead of just putting it in
+* first? */
strbuf_insert(&pathbuf, 0, filename, tree_name_len);
} else {
strbuf_addstr(&pathbuf, filename);
}
+ /* XXX We seem to get all kinds of junk via the filename field here,
+* including partial filenames, sha1:path, etc. We could parse it
+* ourselves, but that is probably insanity. We should ask the
+* caller to break it down more for us. For now, just pass NULL. */
+
#ifndef NO_PTHREADS
if (use_threads) {
- add_work(opt, GREP_SOURCE_SHA1, pathbuf.buf, sha1);
+ add_work(opt, GREP_SOURCE_SHA1, pathbuf.buf, NULL, sha1);
strbuf_release(&pathbuf);
return 0;
} else
@@ -394,7 +401,7 @@ static int grep_sha1(struct grep_opt *opt, const unsigned
char *sha1,
struct grep_source gs;
int hit;
- grep_source_init(&gs, GREP_SOURCE_SHA1, pathbuf.buf, sha1);
+ grep_source_init(&gs, GREP_SOURCE_SHA1, pathbuf.buf, NULL,
sha1);
strbuf_release(&pathbuf);
hit = grep_source(opt, &gs);
@@ -414,7 +421,7 @@ static int grep_file(struct grep_opt *opt, const char
*filename)
#ifndef NO_PTHREADS
if (use_threads) {
- add_work(opt, GREP_SOURCE_FILE, buf.buf, filename);
+ add_work(opt, GREP_SOURCE_FILE, buf.buf, filename, filename);
strbuf_release(&buf);
return 0;
} else
@@ -423,7 +430,7 @@ static int grep_file(struct grep_opt *opt, const char
*filename)
struct grep_source gs;
int hit;
- grep_source_init(&gs, GREP_SOURCE_FILE, buf.buf, filename);
+ grep_source_init(&gs, GREP_SOURCE_FILE, buf.buf, filename,
filename);
strbuf_release(&buf);
hit = grep_source(opt, &gs);
diff --git a/grep.c b/grep.c
index edc7776..06bc1c6 100644
--- a/grep.c
+++ b/grep.c
@@ -1373,7 +1373,7 @@ int grep_buffer(struct grep_opt *opt, char *buf, unsigned
long size)
struct grep_source gs;
int r;
- grep_source_init(&gs, GREP_SOURCE_BUF, NULL, NULL);
+ grep_source_init(&gs, GREP_SOURCE_BUF, NULL, NULL, NULL);
Re: Git ~unusable on slow lines :,'C
>> Bam, the server kicked me off after taking to long to sync my copy. > This is unrelated to git. The HTTP server's configuration is too > impatient. Yes. How does that mean it is unrelated to git? >> - git fetch should show the total amount of data it is about to >> transfer! > It can't, because it doesn't know. The server side doesn't know at how much the objects *it just repacked for transfer* weigh in? If that truly is the case, wouldn't it make sense to make git a little more introspective? f.e. > # git info git://foo.org/bar.git > .. [server generating figures] .. > URL: git://foo.org/bar.git > Created/Earliest commit: ... > Last modified/Latest commit: ... > Total object count: (..commits, ..files, .. directories) > Total repository size (compressed): ... MiB > Branches: > [git branch -va] + branch size > The error message doesn't really know whether it is going to overwrite > it (the CR comes from the server), though I suppose an extra LF wouldn't > hurt there. Definitely wouldn't hurt. >> - would be nice to be able to tell git fetch to get the next chunk of >> say 500 commits instead of trying to receive ALL commits, then b0rking >> after umpteen percent on server timeout. Not? > You asked for the current state of the repository, and that's what its > giving you. And instead, I would rather like to ask for the next 500 commits. No way to do it. > The timeout has nothing to do with git, if you can't > convince the admins to increase it, you can try using another transport > which doesn't suffer from HTTP, as it's most likely an anti-DoS measure. See, I probably can't convince the admins to drop their anti-dos measures. And they (drupal.org admins) probably will not change their allowed protocol policies. Despite that, i've had timeouts or simply stale connections dying down before with other repositories and various transport modes. The easiest fix would be an option to tell git to not fetch everything... > If you want to download it bit by bit, you can tell fetch to download > particular tags. ..without specifying specific commit tags. Browsing gitweb sites to find a tag for which the fetch doesn't time out is hugely inconvenient, especially on a slow line. > Doing this automatically for this would be working > around a configuration issue for a particular server, which is generally > better fixed in other ways. It is not only a configuration issue for one particular server. Git in general is hardly usable on slow lines because - it doesn't show the volume of data that is to be downloaded! - it doesn't allow the user to sync up in steps the circumstances will allow to succeed. #Regards!Marcel. -- 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] configure.ac: Add missing comma to CC_LD_DYNPATH
From: "Øyvind A. Holm"
40bfbde ("build: don't duplicate substitution of make variables",
2012-09-11) breaks make by removing a necessary comma at the end of
"CC_LD_DYNPATH=-rpath" in line 414.
When executing "./configure --with-zlib=PATH", this resulted in
[...]
CC xdiff/xhistogram.o
AR xdiff/lib.a
LINK git-credential-store
/usr/bin/ld: bad -rpath option
collect2: ld returned 1 exit status
make: *** [git-credential-store] Error 1
$
during make.
Signed-off-by: Øyvind A. Holm
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index da1f41f..c85888c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -411,7 +411,7 @@ else
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_wl_rpath" = "yes"; then
- CC_LD_DYNPATH=-Wl,-rpath
+ CC_LD_DYNPATH=-Wl,-rpath,
else
AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
--
1.8.0.rc0.18.gf84667d
--
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: Discussion around a --bindtodev option for git-daemon
On Wednesday 2012-09-26 18:36, Ronan Bignaux wrote: >I wrote this little patch to add a restrict option to bind only to a >specific network interface. > >I'd not deal with --inetd since there are some bugs in xinetd with ipv6 >( and no more maintener ) , systemd/upstart are also Linux centric and >subject to controversy... > >"listen" option was not more useful in my case because it need ip as >parameter (you need fix ip or custom script for example). There is a reason --listen wants an address: because bind(2) binds to addresses, and in principle, that is really what is wanted, since you want to continue being able to connect to your service from-to localhost. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git ~unusable on slow lines :,'C
On Tue, Oct 9, 2012 at 7:06 AM, Marcel Partap wrote: >>> Bam, the server kicked me off after taking to long to sync my copy. >> This is unrelated to git. The HTTP server's configuration is too >> impatient. > Yes. How does that mean it is unrelated to git? It means its out of our control, we cannot modify the HTTP server's configuration to have a longer timeout. We can recommend that the timeout be increased, but as you point out the admins may not do that. >>> - git fetch should show the total amount of data it is about to >>> transfer! >> It can't, because it doesn't know. > The server side doesn't know at how much the objects *it just repacked > for transfer* weigh in? Actually it does. Its just not used here. What value is that to you? You asked for the repository. If you know its size is going to be ~105 MiB you have two choices... continue to get the repository you asked for, or disconnect and give up. Either way the size doesn't help you. It would require a protocol modification to send a size estimate down to the client before the data in order to give the client a better progress meter than the object count (allowing it instead to track by bytes received). But this has been seen as not very useful or worthwhile since it doesn't really help anyone do anything better. So why change the protocol? >> You asked for the current state of the repository, and that's what its >> giving you. > And instead, I would rather like to ask for the next 500 commits. No way > to do it. No, there isn't. Git assumes that once it has commit X, all versions that predate X are already on the local workstation. This is a fundamental assumption that the entire protocol relies on. It is not trivial to change. We have been through this many times on the mailing list, please search the archives for "resumable clone". >> The timeout has nothing to do with git, if you can't >> convince the admins to increase it, you can try using another transport >> which doesn't suffer from HTTP, as it's most likely an anti-DoS measure. > See, I probably can't convince the admins to drop their anti-dos measures. > And they (drupal.org admins) probably will not change their allowed > protocol policies. Then if they are hosting really big repositories that are hard for their contributors to obtain, they should take the time to write a script that periodically creates a bundle file for each repository using `git bundle create repo.bundle --all`. They can host these bundle files in any file transport service like HTTP or BitTorrent, and users can download and resume these using normal HTTP download tools. Once you have a bundle file locally, you can clone from it with modern Git with `git clone $(pwd)/repo.bundle` to initialize the repository. This is currently the best way to support resumable clone. The repo will be stale by whatever time has elapsed since the bundle file was created. But then Git can do an incremental fetch to catch up, and this transfer size should be limited to the progress made since the bundle was made. If bundles are made once per month or after each major release its usually a manageable delta. > It is not only a configuration issue for one particular server. Git in > general is hardly usable on slow lines because > - it doesn't show the volume of data that is to be downloaded! If it did show you, what would you do? Declare defeat before it even starts to download and give up and start a thread about how Git requires too much bandwidth? Have you tried to shallow clone the repository in question? > - it doesn't allow the user to sync up in steps the circumstances will > allow to succeed. Sadly, this is quite true. :-( -- 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] configure.ac: Add missing comma to CC_LD_DYNPATH
From: "Øyvind A. Holm"
40bfbde ("build: don't duplicate substitution of make variables",
2012-09-11) breaks make by removing a necessary comma at the end of
"CC_LD_DYNPATH=-rpath" in line 414 and 423.
When executing "./configure --with-zlib=PATH", this resulted in
[...]
CC xdiff/xhistogram.o
AR xdiff/lib.a
LINK git-credential-store
/usr/bin/ld: bad -rpath option
collect2: ld returned 1 exit status
make: *** [git-credential-store] Error 1
$
during make.
Signed-off-by: Øyvind A. Holm
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index da1f41f..ea79ea2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -411,7 +411,7 @@ else
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_wl_rpath" = "yes"; then
- CC_LD_DYNPATH=-Wl,-rpath
+ CC_LD_DYNPATH=-Wl,-rpath,
else
AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS="${LDFLAGS}"
@@ -420,7 +420,7 @@ else
LDFLAGS="${SAVE_LDFLAGS}"
])
if test "$git_cv_ld_rpath" = "yes"; then
- CC_LD_DYNPATH=-rpath
+ CC_LD_DYNPATH=-rpath,
else
CC_LD_DYNPATH=
AC_MSG_WARN([linker does not support runtime path to dynamic
libraries])
--
1.8.0.rc1
--
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/attr-match-optim-more 2/2] attr: more matching optimizations from .gitignore
Junio C Hamano writes: > Johannes Sixt writes: > >> Am 10/9/2012 7:08, schrieb Junio C Hamano: >>> Imagine if we allowed only one attribute per line, instead of >>> multiple attributes on one line. >>> >>> - If you want to unset the attribute, you would write "path -attr". >>> >>> - If you want to reset the attribute to unspecified, you would >>>write "path !attr". >>> >>> Both are used in conjunction with some other (typically more >>> generic) pattern that sets, sets to a value, and/or unsets the >>> attribute, to countermand its effect. >>> >>> If you were to allow "!path attr", what does it mean? It obviously >>> is not about setting the attr to true or to a string value, but is >>> it countermanding an earlier set and telling us to unset the attr, >>> or make the attr unspecified? >> >> If I have at the toplevel: >> >> *.txt whitespace=tabwidth=4 >> >> and in a subdirectory >> >> *.txt whitespace=tabwidth=8 >> !README.txt >> >> it could be interpreted as "do not apply *.txt to REAME.txt in this >> subdirectory". That is, it does not countermand some _particular_ >> attribute setting, but says "use the attributes collected elsewhere". > > It makes it unclear what "elsewhere" means, though (besides, it does > not match the way the matching logic works at all). Ignoring the current implementation, I find the suggested semantics somewhat intriguing. It is something we may want to look into in the future. -- 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] configure.ac: Add missing comma to CC_LD_DYNPATH
Please discard the first patch, I reckon line 423 also should be changed. Sorry about the noise, Øyvind -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git ~unusable on slow lines :,'C
c...@elego.de (Carlos Martín Nieto) writes: > If you want to download it bit by bit, you can tell fetch to download > particular tags. Doing this automatically for this would be working > around a configuration issue for a particular server, which is generally > better fixed in other ways. As part of an upcoming "protocol update" discussion, we may want to include allowing "upload-pack" to accept a request for commit that is not at the tip of any ref. E.g. "want refs/heads/master~*0.1" might ask "I know your entire history is very big; please give me only the one tenth of the oldest history during this round." (this is not a suggestion on how to do this at the UI level). -- 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 report
On 10/7/12 6:52 PM, Jeff King wrote:
Yes, but does that really have to be an issue? Is there any technical
or practical reason you can think of that the repository shouldn't
ignore those CRs?
It's significantly less efficient. Right now git only has to do the
conversion when updating the index cache of what's on the filesystem
(i.e., when it would be doing a sha1 over the file contents _anyway_).
And then it can compare sha1s internally, because it knows that all of
the sha1s it has computed are for the canonical in-repo versions of the
file.
If we assume that the in-repo file might need to have CRs stripped, then
we need to actually follow up every sha1 mismatch with an actual content
diff in order to discover if it really is different or not. We could
cache the "true" sha1 of the canonical stripped version to avoid this,
but now we are getting much more complex. In most cases it is sufficient
to just commit the cleaned up contents and then never worry about it
again.
You're right, we can't magically avoid all the line ending issues
that people will run into. In this case, though, I think git can
sidestep a fairly obnoxious problem. My example was simple, but when
you've got multiple branches that need to be rebased/merged, it can
get pretty hairy. The repository will never be truly "clean" unless
you rewrite the whole thing (using filter-branch, for instance).
Right. Git's current approach is very hairy when you are looking at
history that crosses a CRLF flag-day boundary. It's definitely a
weakness of the canonicalization approach. But other approaches also
have downsides; I don't want to catalogue them all here, but you can
certainly search the archive for various discussions and flamewars about
how line endings are handled.
Maybe my above suggestion is more of a feature request than a bug,
Fair enough. I think your complaint is real, but I think nobody has been
clever enough yet to devise a solution that does not have too many other
downsides. And of course you are free to propose such an approach if you
have thought of one. :)
but there is the obvious bug that after changing .gitattributes, git
still doesn't notice that files are "modified" until you modify them
again in some way (touch works). I only noticed the CRs in our own
repository after I tried to rebase a branch and got strange errors.
To make git notice all the files, I had to "find . -type f -exec
touch {} \;".
I think the idea has been floated before of unconditionally refreshing
the index when you update the crlf config via "git config". But of
course that can only fix a fraction of the cases. You might edit it with
an editor. Or they may be new lines in .gitattributes. Or a change of
wildcard lines in .gitattributes.
Really, the issue is that the index contains a cache of what's in the
files that is considered valid unless the stat information of the file
changes. But that is obviously not the full story, as the
canonicalization rules (CRLF handling or smudge/clean filters) can
change, too, and that is not considered as part of the cache's validity.
Doing it "right" would mean that anytime the attributes or config files
changed, we would consider the cache entry dirty and re-read (and
re-canonicalize) the file.
But that has either:
1. Bad complexity. It means our cache validity needs to know about
exactly which rules were applied to yield the cached sha1. And
those rules can be complex, consisting of wildcard matching,
cross-referencing custom filters from config, etc.
2. Bad performance. If you instead just invalidate cached sha1s when
the gitattributes or .git/config file changes, you catch way too
many cases. E.g., if you checkout a branch that changes
.gitattributes, we have to re-read every file in the repository,
even though most of them will not be affected.
So I think it's possible to handle this case correctly, but doing it
right is quite complex. So we have the "just manually poke the files
when you make such a change". Which is a horrible user experience, but
works OK in practice (and many people do not run into it at all, because
on new projects they set the filter attributes very early on, before
they have an existing history).
IOW, no, it is not pretty, but these are all known issues that nobody
has felt it worth tackling yet.
-Peff
Thank you very much for your detailed explanations. I suspected that
efficiency concerns might be preventing a clean solution.
How about this idea... When git stores files, it could include a bit of
metadata that tells it whether the file is a binary blob or text.
(Perhaps it already does this?) If a binary blob (in the repository) is
being compared with a text file (on the filesystem), git could
re-process the blob and get the "sha1 of the canonical stripped
version". In all other situations, the original SHA1 should be correct,
since git already removes CRs from the line endings in files it
recognizes as text.
Re: Git ~unusable on slow lines :,'C
- git fetch should show the total amount of data it is about to transfer! >>> It can't, because it doesn't know. >> The server side doesn't know at how much the objects *it just repacked >> for transfer* weigh in? > Actually it does. Then, please, make it display it. > What value is that to you? The size that is to be transferred, and the total repository size. > You asked for the repository. If you know its size is going to be ~105 > MiB you have two choices... continue to get the repository you asked > for, or disconnect and give up. > Either way the size doesn't help you. Yes it does - when displayed, one could make an informed choice. But it doesn't show this, just the object count.. and that is of low expressiveness. It so happened last week that I tried cloning a repository with a seemingly moderate amount of objects and small code base. However, full Java RE zips had been checked in and updated multiple times - suddenly my monthly 3G traffic limit was exhausted. Needless to say without a clue how much more data would follow, I aborted the transfer - and was left with a net result of *zilch* bytes of code, and a line cut down to ridiculous speed. Now I can't even sync up my Drupal copy. > It would require a protocol modification to send a size estimate down > to the client before the data in order to give the client a better > progress meter than the object count (allowing it instead to track by > bytes received). Well, if it requires that, so be it. I fail to understand why this wasn't considered before. > But this has been seen as not very useful or worthwhile > since it doesn't really help anyone do anything better. Huh? > So why change the protocol? Sanity? Usability of git with slow lines? > Git assumes that once it has commit X, all versions > that predate X are already on the local workstation. And that's true for all my repositories, since none of them was cloned --shallow. > This is a fundamental assumption that the entire protocol relies on. What about --shallow, --depth? > It is not trivial to change. Many changes for the better are not trivial. And still worth it. > We have been through this many times on the mailing > list, please search the archives for "resumable clone". Ok - yet that probably doesn't invalidate all arguments in favor of it. > they should [...] host these bundle files [...] > and users can download and resume these Thanks for the tip, I will forward it to the server administrators. However, this does not help to handle the huge amount of commits to fetch that pile up within a couple of months. > This is currently the best way to support resumable clone. I wasn't even mentioning that, but that'd be nice to have aswell^^... > If bundles are made once per month or after each > major release its usually a manageable delta. While downloading bundle delta files definitely is a plausible solution - isn't that quite far from user friendly? > If it did show you, what would you do? Not try to checkout a repository full of JRE zips blindfolded? > Declare defeat before it even > starts to download and give up and start a thread about how Git > requires too much bandwidth? Kindly ask the author to locally rewrite his history and recreate the repository with *LINKS* to JRE zips instead? Not for a second did I doubt the efficiency of git's packing and compression algorithms! That's why I'm quite amazed about the shear existence of these issues of not showing the repository size before downloading (or, IIUC, *anywhere*) and a protocol that is incapable of resuming or partly fetching a repository, even though it obviously provides means of negotiation between server and client.. Just boggles me that within 7+ years of development this hasn't been addressed (disclaimer: I do not claim to grok the protocol - not wanting to put blame on anyone here :). > Have you tried to shallow clone the repository in question? No - would it allow me to fuse the two repositories afterwards? That'd actually be quite cool and a good idea to instantly solve my current problem... gonna try that, thx :) #Regards!Marcel -- 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] configure.ac: Add missing comma to CC_LD_DYNPATH
On 9 October 2012 19:05, Junio C Hamano wrote:
> Øyvind A. Holm writes:
> > 40bfbde ("build: don't duplicate substitution of make variables",
> > 2012-09-11) breaks make by removing a necessary comma at the end of
> > "CC_LD_DYNPATH=-rpath" in line 414 and 423.
>
> The earlier one is a cut-and-paste-error regression.
>
> Isn't the one at line 423 from before 40bfbde, though? If that is the
> case, I'm a bit hesitant to take that part of this patch without a
> second opinion.
It looks like it is, yes. More accurately, from 798a945 way back in
2008. If it hasn't caused any trouble since then, it probably won't. :)
The line was changed in 40bfbde, though, but AC_SUBST doesn't contain a
comma, so to be on the safe side, the first patch should be used.
But I made a minor copy+paste error in the commit message of that patch:
"CC_LD_DYNPATH=-rpath" in line 414.
should be
"CC_LD_DYNPATH=-Wl,-rpath" in line 414.
Just a minor, but slightly annoying detail.
Regards,
Øyvind
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git clone algorithm
I have already posted this message on git-us...@googlegroups.com but I have been advised to rather use this list. I know that there is a related thread (http://thread.gmane.org/gmane.comp.version-control.git/207257), but I don't think that this provides an answer to my question (me too I am on a slow 3G connection :)) I am wondering what algorithm is used by git clone command ? When cloning from remote repositories, if there is a link failure and the same command is issued again, the process should be smart enough to figure out what objects have been already transferred locally and restart the cloning process from the point it has been interrupted. As far as I can tell this is not the case, each time I have restarted the cloning process everything started from the beginning. This is extremely annoying with slow, unreliable connections. Are there any ways to cope with this situation or any future plans ? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git ~unusable on slow lines :,'C
Marcel Partap writes: >>> Bam, the server kicked me off after taking to long to sync my copy. >> This is unrelated to git. The HTTP server's configuration is too >> impatient. > Yes. How does that mean it is unrelated to git? > >>> - git fetch should show the total amount of data it is about to >>> transfer! >> It can't, because it doesn't know. > The server side doesn't know at how much the objects *it just repacked > for transfer* weigh in? > If that truly is the case, wouldn't it make sense to make git a little > more introspective? f.e. It sends you more objects than the ones it just repacked in the normal case. It could tell you, but it would have to keep track of more information (which would make it take longer for the first bytes to get to you) for little gain. The only thing you'd be able to do is to abort the transfer immediately, but you can do that anyway, and waiting is only going to add history to download. >> # git info git://foo.org/bar.git >> .. [server generating figures] .. >> URL: git://foo.org/bar.git >> Created/Earliest commit: ... >> Last modified/Latest commit: ... >> Total object count: (..commits, ..files, .. directories) >> Total repository size (compressed): ... MiB >> Branches: >> [git branch -va] + branch size > >> The error message doesn't really know whether it is going to overwrite >> it (the CR comes from the server), though I suppose an extra LF wouldn't >> hurt there. > Definitely wouldn't hurt. > >>> - would be nice to be able to tell git fetch to get the next chunk of >>> say 500 commits instead of trying to receive ALL commits, then b0rking >>> after umpteen percent on server timeout. Not? >> You asked for the current state of the repository, and that's what its >> giving you. > And instead, I would rather like to ask for the next 500 commits. No way > to do it. Do you mean that there are no tags in between your current state and the one you want to be at? > >> The timeout has nothing to do with git, if you can't >> convince the admins to increase it, you can try using another transport >> which doesn't suffer from HTTP, as it's most likely an anti-DoS measure. > See, I probably can't convince the admins to drop their anti-dos measures. > And they (drupal.org admins) probably will not change their allowed > protocol policies. Switch to using the raw git protocol, which is much less likely to have this sort of measure. > Despite that, i've had timeouts or simply stale connections dying down > before with other repositories and various transport modes. > The easiest fix would be an option to tell git to not fetch everything... > >> If you want to download it bit by bit, you can tell fetch to download >> particular tags. > ..without specifying specific commit tags. > Browsing gitweb sites to find a tag for which the fetch doesn't time out > is hugely inconvenient, especially on a slow line. Don't use the web then. Use ls-remote to see what's at the other end. > >> Doing this automatically for this would be working >> around a configuration issue for a particular server, which is generally >> better fixed in other ways. > It is not only a configuration issue for one particular server. Git in > general is hardly usable on slow lines because > - it doesn't show the volume of data that is to be downloaded! How would showing the amount of data help your connection? > - it doesn't allow the user to sync up in steps the circumstances will > allow to succeed. This is unfortunate is some circunstances, but you haven't shown that yours is one of these. cmn -- 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
username case conflict in git svn clone
Hi, Can anyone help me with a username case conflict in git svn clone? Running `git svn clone svn://svn.example.com/project --no-metadata -A users.txt project` whenusers.txt contains: juser Joe User JUser Joe User returns: Initialized empty Git repository in /var/git/SCE/sce/.git/ A a.txt A b.txt Author: JUser not defined in users.txt file I was hoping that the two versions of the username would be replaced with the same details, but apparently not. Any ideas? Cheers, Dave. -- David Balch. | Señor web developer. T: +44 (0)1865 280979 | Technology-Assisted Lifelong Learning. W: www.tall.ox.ac.uk | University of Oxford. E: david.ba...@conted.ox.ac.uk -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Andreas Schwab writes: > Angelo Borsotti writes: > >> If they are specified after -b, the command seems to behave as if -b >> was not specified, e.g.: >> >> $ git checkout -b --no-track topic remotes/origin/master > > -b requires an argument , which you specify as --no-track > here. is topic, and the rest is interpreted as . > >> fatal: git checkout: updating paths is incompatible with switching branches. > > This error is detected before validating . > >> while if they are specified before -b the command behaves properly, e.g. >> >> $ git checkout --no-track -b topic remotes/origin/master >> Switched to a new branch 'topic' > > You can also specify --no-track after -b (and its argument): > > $ git checkout -b topic --no-track remotes/origin/master Isn't this "asked and answered" recently with this thread? http://thread.gmane.org/gmane.comp.version-control.git/204397 -- 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: username case conflict in git svn clone
David Balch writes: > whenusers.txt contains: > > juser Joe User > > JUser Joe User Reread the manual. Hint: there must be an equal sign. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] submodule: teach "foreach" command a --revision option
Jay Soffian writes: > On Tue, Oct 9, 2012 at 2:12 AM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Assuming that the above guess is correct (which is a huge >>> assumption, given the lack of clarity in the description), I think >>> the feature might make sense. The example would have been a lot >>> easier to follow if it were something like this: >>> >>> $ git submodule foreach --revision v1.0 'git grep -e frotz $sha1' >> >> Imagine you have a checkout of v2.0 of the superproject in your >> working tree, and you run "git submodule foreach --revision v1.0". >> Further imagine a submodule S that used to exist back when the >> superproject was at v1.0 no longer exists in the current codebase >> (hence there is no such submodule in the working tree). >> >> Shouldn't the above "foreach ... grep" still try to find 'frotz' in >> the submodule S that was bound to v1.0 of the superproject? >> >> Given that your patch does not touch the part of cmd_foreach where >> it decides which submodule to descend into, it still will base its >> decision solely on the set of submodules that are bound to and have >> been "git submodule init"ed in the version of the superproject that >> is _currently_ checked out, no? > > That's a good observation. My use-case for this (poorly explained in > ... > As you previously stated, I need to improve the documentation that > goes along with this patch, so I'll call-out this limitation. I'm not > sure what else can be done. You can't descend into a submodule that > isn't there. As recent "submodule rm" work by Jens indicates, since 501770e (Move git-dir for submodules, 2011-08-15), you should be able to peek into submodules that have been "git submodule init"ed but do not exist in the current checkout of the superproject. I think the right approach to implement this "recurse foreach in the superproject tree that is not checkout out to the working tree" feature should be: - Advertise it so that it is crystal clear that the command run by "foreach" may have to run in a bare repository of submodule to look at submodule's commit bound to the historical tree of the superproject; - Anytime you look at .gitmodules in the superproject, read from the historical tree's .gitmodules instead of from the working tree (I think this is necessary in order to get the $sm_name vs $sm_path mapping right); and - Locate submodule's $GIT_DIR in $GIT_DIR/modules/$sm_name of the superproject that corresponds to the submodule found in the historical tree in the superproject (or if it is the same repository as that is currently checked out, use $sm_path/.git), and error out when it is not available. An implementation that works only when all the submodules necessary in the historical tree in the superproject are still in the current checkout of the superproject may be fine as a quick throw-away hack, and it may even be acceptable as a good first step towards the real feature, but at least it needs to be protected by an error checking upfront (perhaps running "diff-tree -r" between the index and the historical tree to make sure there are no removed submodules that existed in the historical tree), if it does not bother to check with $GIT_DIR/modules/$sm_name in the superproject. Jens, anything I missed? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
Jeff King writes: > I think we just need to have callers of grep_source_init provide us with > the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is > where the information is lost. Yes. I agree that is the right approach. -- 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 report
On 10/9/12 12:17 PM, John Whitney wrote: Thank you very much for your detailed explanations. I suspected that efficiency concerns might be preventing a clean solution. How about this idea... When git stores files, it could include a bit of metadata that tells it whether the file is a binary blob or text. (Perhaps it already does this?) If a binary blob (in the repository) is being compared with a text file (on the filesystem), git could re-process the blob and get the "sha1 of the canonical stripped version". In all other situations, the original SHA1 should be correct, since git already removes CRs from the line endings in files it recognizes as text. I would think that this solution would have no performance penalty for "fixed" repositories. (It would only have a small performance hit when binary blobs are compared against text files, which is rare even in broken repositories.) Git could even throw a warning like: "File xyz.txt was originally stored as a binary blob." What do you think? ---John I'm going to reply to myself, to save you the trouble of replying. (You've been very helpful and I do appreciate it.) I guess the problem with this idea is that git doesn't have any way to distinguish between binary blobs and text files in the repository. I think it would be useful information, but I guess that bridge burned a long time ago. So any metadata would have to be stored separately. Jeff, that's roughly equivalent to your idea of caching, which would take a lot of work to implement. Thank you so much for helping me to understand the reason git behaves the way it does. It's a great tool! ---John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Inconsistency in specifying commit & path for git diff
git diff .. and git diff both succeed however git diff :..: fails while git diff : : succeeds OS X 10.7.5 git version 1.7.9.1 Reproduced by another user: http://stackoverflow.com/questions/12805004/git-cherry-pick-creates-blobs-not-commits#comment17319876_12805004 It seems logical to support the '..' syntax in both for consistency. -- 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] Add --unannotate option to git-subtree
This new option does the reverse of --annotate, which is more useful
when contributing back to a library which is also included in the
repository for a larger project, and perhaps in other situations as
well.
Rather than adding a marker to each commit when splitting out the
commits back to the subproject, --unannotate removes the specified
string (or bash glob pattern) from the beginning of the first line of
the commit message. This enables the following workflow:
- Commit to a library included in a large project, with message:
Library: Make some amazing change
- Use `git-subtree split` to send this change to the library maintainer
- Pass ` --unannotate='Library: ' ` or ` --unannotate='*: ' `
- This will turn the commit message for the library project into:
Make some amazing change
This helps to keep the commit messages meaningful in both the large
project and the library project.
Signed-off-by: James Nylen
---
Let me know if gmail has munged this patch. You can also get at it
like this:
$ git remote add nylen git://github.com/nylen/git.git
$ git fetch nylen
$ git show nylen/subtree-unannotate
---
contrib/subtree/git-subtree.sh | 11 +--
contrib/subtree/git-subtree.txt | 15 +++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..8d1ed05 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,6 +21,7 @@ P,prefix= the name of the subdir to split out
m,message=use the given message as the commit message for the merge commit
options for 'split'
annotate= add a prefix to commit message of new commits
+unannotate= remove a prefix from new commit messages (supports bash globbing)
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
@@ -43,6 +44,7 @@ onto=
rejoin=
ignore_joins=
annotate=
+unannotate=
squash=
message=
@@ -80,6 +82,8 @@ while [ $# -gt 0 ]; do
-d) debug=1 ;;
--annotate) annotate="$1"; shift ;;
--no-annotate) annotate= ;;
+ --unannotate) unannotate="$1"; shift ;;
+ --no-unannotate) unannotate= ;;
-b) branch="$1"; shift ;;
-P) prefix="$1"; shift ;;
-m) message="$1"; shift ;;
@@ -310,8 +314,11 @@ copy_commit()
GIT_COMMITTER_NAME \
GIT_COMMITTER_EMAIL \
GIT_COMMITTER_DATE
- (echo -n "$annotate"; cat ) |
- git commit-tree "$2" $3 # reads the rest of stdin
+ (
+ read FIRST_LINE
+ echo "$annotate${FIRST_LINE#$unannotate}"
+ cat # reads the rest of stdin
+ ) | git commit-tree "$2" $3
) || die "Can't copy commit $1"
}
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 0c44fda..ae420aa 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -198,6 +198,21 @@ OPTIONS FOR split
git subtree tries to make it work anyway, particularly
if you use --rejoin, but it may not always be effective.
+--unannotate=::
+ This option is only valid for the split command.
+
+ When generating synthetic history, try to remove the prefix
+from each commit message (using bash's "strip
+ shortest match from beginning" command, which supports
+ globbing). This makes sense if you format library commits
+ like "library: Change something or other" when you're working
+ in your project's repository, but you want to remove this
+ prefix when pushing back to the library's upstream repository.
+ (In this case --unannotate='*: ' would work well.)
+
+ Like --annotate, you need to use the same
+ whenever you split, or you may run into problems.
+
-b ::
--branch=::
This option is only valid for the split command.
--
1.7.11.3
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: upload-pack is slow with lots of refs
Am 09.10.2012 08:46, schrieb Shawn Pearce:
> On Mon, Oct 8, 2012 at 8:05 AM, Johannes Sixt wrote:
>> Am 05.10.2012 18:57, schrieb Shawn Pearce:
>>> Smart HTTP is not bidirectional. The client can't cut off the server.
>>
>> Smart HTTP does not need it: you already posted a better solution (I'm
>> refering to "&v=2").
>
> Yes but then it diverges even further from the native bidirectional protocol.
I won't argue here because I know next to nothing about Smart HTTP. But
it sounds like you either have compatibility, but a diverging protocol
or at least implementation, or no compatibility.
>> +static int client_spoke(void)
>> +{
>> + struct pollfd pfd;
>> + pfd.fd = 0;
>> + pfd.events = POLLIN;
>> + return poll(&pfd, 1, 0) > 0 &&
>> + (pfd.revents & (POLLIN|POLLHUP));
>
> Except doing this in Java is harder on an arbitrary InputStream type.
> I guess we really only care about basic TCP, in which case we can use
> NIO to implement an emulation of poll, and SSH, where MINA SSHD
> probably doesn't provide a way to see if the client has given us data
> without blocking. That makes supporting v2 really hard in e.g. Gerrit
> Code Review. You could argue that its improper to attempt to implement
> a network protocol in a language whose standard libraries have gone
> out of their way to prevent you from polling to see if data is
> immediately available, but I prefer to ignore such arguments.
Can't you read the inbound stream in a second thread while the first
thread writes the advertisements to the outbound stream? Then you don't
even need to poll; you can just read the 4-byte length header, stash it
away and set a flag. The implementation of client_spoke() would only
amount to check that flag.
> As it turns out we don't really have this problem with git://. Clients
> can bury a v2 request in the extended headers where the host line
> appears today.
I tried, but it seems that todays git-daemons are too strict and accept
only \0host=foo\0, nothing else :-(
-- 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: Inconsistency in specifying commit & path for git diff
Arthur Etchells writes: > git diff :..: : represents a tree or blob, but .. requires commits as its end points. (You can dereference a commit to get a tree or blob, but not the other way round.) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: upload-pack is slow with lots of refs
Am 09.10.2012 22:30, schrieb Johannes Sixt: > Am 09.10.2012 08:46, schrieb Shawn Pearce: >> As it turns out we don't really have this problem with git://. Clients >> can bury a v2 request in the extended headers where the host line >> appears today. > > I tried, but it seems that todays git-daemons are too strict and accept > only \0host=foo\0, nothing else :-( I take that back: Modern git-daemons accept "\0host=foo\0\0version=2\0", as you said. It looks like SSH is the only stubborn protocol. -- 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 4/8] wildmatch: remove static variable force_lower_case
Nguyễn Thái Ngọc Duy writes: > diff --git a/wildmatch.c b/wildmatch.c > index 7b64a6b..2382873 100644 > --- a/wildmatch.c > +++ b/wildmatch.c > @@ -11,8 +11,8 @@ > > #include > #include > -#include > > +#include "cache.h" > #include "wildmatch.h" This is wrong; the includes from the system headers should have been removed in the previous step where the series "integrated" wildmatch to git, after which point the first include any C source that is not at the platform-compatibility layer should be cache.h or git-compat-util.h. -- 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: Inconsistency in specifying commit & path for git diff
Arthur Etchells writes: > git diff .. > and > git diff > both succeed > however > git diff :..: > fails while > git diff : : > succeeds > ... > It seems logical to support the '..' syntax in both for consistency. "git diff A..B" is an illogical thing to say in the first place. It only happens to work by historical accident, and for that "it used to work like so from the beginning, do not break backward compatibility" reason, we have kept it working. But you are better off unlearning it to keep your sanity when learning git as a new user. The dot notation is about a range. A..B talks about the set of commits that are ancestors of B but not ancestors of A. $ git log A..B makes perfect sense to show such a range. But "diff" is about "comparing two endpoints". There is nothing "range" about such a comparison. When you compare the state at A and at B, you do not even look at anything in between. That is why the canonical way to say it is $ git diff A B and not $ git diff A..B ;# WRONG. DO NOT DO THIS. And : is a way to name an entity at in the tree recorded in the . Typically you name a blob, not a tree that represents a subdirectory, with this syntax. Now, B1..B2, when B1 and B2 are blobs (or anything that is not commit-ish), does not make sense even as a range, and such a request is detected as an error at the syntactic level (i.e. without even starting to "compare"). $ git diff HEAD:Makefile..HEAD~4:Makefile ;# WRONG. DO NOT DO THIS. If you want to compare two blobs, you can do so with the canonical "compare two things" syntax. $ git diff HEAD:Makefile HEAD~4:Makefile -- 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] configure.ac: Add missing comma to CC_LD_DYNPATH
[Re-sending because I forgot to CC: the list, sorry]
On 10/09/2012 06:36 PM, Øyvind A. Holm wrote:
> From: "Øyvind A. Holm"
>
> 40bfbde ("build: don't duplicate substitution of make variables",
> 2012-09-11)
>
Oops, stupid copy and paste error on my part. Sorry.
> breaks make by removing a necessary comma at the end of
> "CC_LD_DYNPATH=-rpath" in line 414 and 423.
>
Here, s/-rpath/-Wl,-rpath/, as you've noted yourself in a follow-up
message. And the reference to "line 423" should be removed.
Also, as a very minor nit, I'd write "might break make" rather then
"breaks make", because the breakage depends on which code path is
taken at configure time (and that's why I hadn't noticed the error
until now -- I never ran configure with the '--with-zlib' option).
> When executing "./configure --with-zlib=PATH", this resulted in
>
> [...]
> CC xdiff/xhistogram.o
> AR xdiff/lib.a
> LINK git-credential-store
> /usr/bin/ld: bad -rpath option
> collect2: ld returned 1 exit status
> make: *** [git-credential-store] Error 1
> $
>
> during make.
>
Indeed, I can reproduce and confirm this error :-(
> Signed-off-by: Øyvind A. Holm
> ---
> configure.ac | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index da1f41f..ea79ea2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -411,7 +411,7 @@ else
>LDFLAGS="${SAVE_LDFLAGS}"
> ])
> if test "$git_cv_ld_wl_rpath" = "yes"; then
> - CC_LD_DYNPATH=-Wl,-rpath
> + CC_LD_DYNPATH=-Wl,-rpath,
> else
>AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
> SAVE_LDFLAGS="${LDFLAGS}"
> @@ -420,7 +420,7 @@ else
> LDFLAGS="${SAVE_LDFLAGS}"
>])
>if test "$git_cv_ld_rpath" = "yes"; then
> - CC_LD_DYNPATH=-rpath
> + CC_LD_DYNPATH=-rpath,
>
And as Junio noted, this second hunk is unneeded, and in fact wrong.
Just remove it please.
With that done,
Acked-by: Stefano Lattarini
>else
> CC_LD_DYNPATH=
> AC_MSG_WARN([linker does not support runtime path to dynamic
> libraries])
Thanks,
Stefano
--
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] submodule: teach "foreach" command a --revision option
Am 09.10.2012 20:24, schrieb Junio C Hamano: > Jay Soffian writes: > >> On Tue, Oct 9, 2012 at 2:12 AM, Junio C Hamano wrote: >>> Junio C Hamano writes: >>> Assuming that the above guess is correct (which is a huge assumption, given the lack of clarity in the description), I think the feature might make sense. The example would have been a lot easier to follow if it were something like this: $ git submodule foreach --revision v1.0 'git grep -e frotz $sha1' >>> >>> Imagine you have a checkout of v2.0 of the superproject in your >>> working tree, and you run "git submodule foreach --revision v1.0". >>> Further imagine a submodule S that used to exist back when the >>> superproject was at v1.0 no longer exists in the current codebase >>> (hence there is no such submodule in the working tree). >>> >>> Shouldn't the above "foreach ... grep" still try to find 'frotz' in >>> the submodule S that was bound to v1.0 of the superproject? >>> >>> Given that your patch does not touch the part of cmd_foreach where >>> it decides which submodule to descend into, it still will base its >>> decision solely on the set of submodules that are bound to and have >>> been "git submodule init"ed in the version of the superproject that >>> is _currently_ checked out, no? >> >> That's a good observation. My use-case for this (poorly explained in >> ... >> As you previously stated, I need to improve the documentation that >> goes along with this patch, so I'll call-out this limitation. I'm not >> sure what else can be done. You can't descend into a submodule that >> isn't there. > > As recent "submodule rm" work by Jens indicates, since 501770e (Move > git-dir for submodules, 2011-08-15), you should be able to peek into > submodules that have been "git submodule init"ed but do not exist in > the current checkout of the superproject. > > I think the right approach to implement this "recurse foreach in the > superproject tree that is not checkout out to the working tree" > feature should be: > > - Advertise it so that it is crystal clear that the command run by >"foreach" may have to run in a bare repository of submodule to >look at submodule's commit bound to the historical tree of the >superproject; I think we should even try to enforce that the user shouldn't use the work tree at all (although at the moment I can't come up with an idea how we could do that), as the work tree *will* be out of sync almost always when you need this option. Otherwise strange things would happen when using "git submodule foreach --revision ..." with a command which examines the work tree, as that won't be updated to the given revision. > - Anytime you look at .gitmodules in the superproject, read from >the historical tree's .gitmodules instead of from the working >tree (I think this is necessary in order to get the $sm_name vs >$sm_path mapping right); and Yes, that is definitely necessary in case submodules are added, removed or moved. > - Locate submodule's $GIT_DIR in $GIT_DIR/modules/$sm_name of the >superproject that corresponds to the submodule found in the >historical tree in the superproject (or if it is the same >repository as that is currently checked out, use $sm_path/.git), >and error out when it is not available. Looking in $GIT_DIR/modules/$sm_name could make sense to tag even those submodules which aren't currently populated. But IIRC the tags in such repositories could not be pushed using current git even when you use the "--recurse-submodules" option because that only honors populated submodules. So for now it would suffice to only recurse into populated submodules. > An implementation that works only when all the submodules necessary > in the historical tree in the superproject are still in the current > checkout of the superproject may be fine as a quick throw-away hack, > and it may even be acceptable as a good first step towards the real > feature, but at least it needs to be protected by an error checking > upfront (perhaps running "diff-tree -r" between the index and the > historical tree to make sure there are no removed submodules that > existed in the historical tree), if it does not bother to check with > $GIT_DIR/modules/$sm_name in the superproject. > > Jens, anything I missed? Nothing I can think of right now, the above is a pretty good summary. My gut feeling is that having "git submodule foreach --revision ..." recurse through submodules whose work trees are out of sync is pretty fragile and could easily lead to inconsistencies. So I tend to think adding a custom script to the release process Jay uses which does the tagging itself might be a better solution here. Opinions? -- 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] git-send-email: use locale encoding for compose
Krzysztof Mazur writes:
> The introduction email (--compose option) use UTF-8 as default encoding.
> The current locale encoding is much better default value.
>
> Signed-off-by: Krzysztof Mazur
> ---
> git-send-email.perl | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 107e814..139bb35 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -590,6 +590,16 @@ sub get_patch_subject {
> die "No subject line in $fn ?";
> }
>
> +sub locale_encoding {
> + my $encoding = "UTF-8";
> + eval {
> + require I18N::Langinfo;
> + I18N::Langinfo->import(qw(langinfo CODESET));
> + $encoding = langinfo(CODESET());
> + };
> + return $encoding;
> +}
> +
> if ($compose) {
> # Note that this does not need to be secure, but we will make a small
> # effort to have it be unique
> @@ -643,7 +653,7 @@ EOT
> } elsif (/^\n$/) {
> $in_body = 1;
> if (!defined $compose_encoding) {
> - $compose_encoding = "UTF-8";
> + $compose_encoding = locale_encoding();
> }
> if ($need_8bit_cte) {
> print $c2 "MIME-Version: 1.0\n",
These two patches make sense in general, but t9001.62 (--compose
adds MIME for utf8 body) seems to be broken by it. I didn't check
to see if the code is broken, or the test has expecting a wrong
behaviour. If the latter, the test needs to be updated to match the
improved new world order.
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] submodule: teach "foreach" command a --revision option
On Tue, Oct 9, 2012 at 5:21 PM, Jens Lehmann wrote: > Nothing I can think of right now, the above is a pretty good summary. > My gut feeling is that having "git submodule foreach --revision ..." > recurse through submodules whose work trees are out of sync is pretty > fragile and could easily lead to inconsistencies. So I tend to think > adding a custom script to the release process Jay uses which does the > tagging itself might be a better solution here. Opinions? I agree now that this is a perilous option, and that its use case may be so narrow that it may not worth adding. I am indeed already using a custom script, and maybe I should leave it at that. j. -- 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] submodule: teach "foreach" command a --revision option
Jens Lehmann writes: > Am 09.10.2012 20:24, schrieb Junio C Hamano: > ... >> I think the right approach to implement this "recurse foreach in the >> superproject tree that is not checkout out to the working tree" >> feature should be: >> >> - Advertise it so that it is crystal clear that the command run by >>"foreach" may have to run in a bare repository of submodule to >>look at submodule's commit bound to the historical tree of the >>superproject; > > I think we should even try to enforce that the user shouldn't use > the work tree at all (although at the moment I can't come up with > an idea how we could do that), as the work tree *will* be out of > sync almost always when you need this option. Very good point. >> - Locate submodule's $GIT_DIR in $GIT_DIR/modules/$sm_name of the >>superproject that corresponds to the submodule found in the >>historical tree in the superproject (or if it is the same >>repository as that is currently checked out, use $sm_path/.git), >>and error out when it is not available. > > Looking in $GIT_DIR/modules/$sm_name could make sense to tag even > those submodules which aren't currently populated. But IIRC the > tags in such repositories could not be pushed using current git > even when you use the "--recurse-submodules" option because that > only honors populated submodules. So for now it would suffice to > only recurse into populated submodules. There are million reasons why we shouldn't lightly think "recurse submodules is a good idea", and I think this may be one of them. But you can always go to $GIT_DIR/modules/$sm_name and push from there, so I do not see it as a huge problem. >> Jens, anything I missed? > > Nothing I can think of right now, the above is a pretty good summary. > My gut feeling is that having "git submodule foreach --revision ..." > recurse through submodules whose work trees are out of sync is pretty > fragile and could easily lead to inconsistencies. So I tend to think > adding a custom script to the release process Jay uses which does the > tagging itself might be a better solution here. Opinions? Well, I am not a good judge for that, as I've never been a big fan of "submodule recurse" myself anyway. But I think an addition that works only when the user never uses commands that use the working tree or the index is still a good thing to have. We could export a magic environment while running foreach script and make NEED_WORK_TREE check fail when it is set, or something, but we need to be careful about performance implications. "foreach" is not something that is worth sacrificing the general performance over. -- 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] git-send-email: use locale encoding for compose
On Tue, Oct 09, 2012 at 02:34:59PM -0700, Junio C Hamano wrote:
> Krzysztof Mazur writes:
>
> > The introduction email (--compose option) use UTF-8 as default encoding.
> > The current locale encoding is much better default value.
> >
>
> These two patches make sense in general, but t9001.62 (--compose
> adds MIME for utf8 body) seems to be broken by it. I didn't check
> to see if the code is broken, or the test has expecting a wrong
> behaviour. If the latter, the test needs to be updated to match the
> improved new world order.
>
> Thanks.
The second patch was broken - for C locale the ANSI_X3.4-1968 codeset
was used, which is insane because git-send-email adds Content-Type
only when non-ASCII characters were found. I think this can be fixed
by just using UTF-8 if langinfo returns ANSI_X3.4-1968.
However I think that that patch should be dropped for now, because also
other git commands like "git commit" don't use codeset from locale.
The git commit just detects invalid UTF-8 characters and prints hint
for user to set i18n.commitencoding. If you like the idea of using codeset
from locale I can send fixed patch and also change "git commit".
For now I think it's better to just take only the first patch.
I'm resending the first patch with added tests.
Thanks,
Chris
---
>From 0d1fccc5e70367f3eeb2372b8fc24401bf88d748 Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur
Date: Wed, 10 Oct 2012 00:17:29 +0200
Subject: [PATCH] git-send-email: introduce compose-encoding
The introduction email (--compose option) have encoding hardcoded to
UTF-8, but invoked editor may not use UTF-8 encoding.
The encoding used by patches can be changed by the "8bit-encoding"
option, but this option does not have effect on introduction email
and equivalent for introduction email is missing.
Added compose-encoding command line option and sendemail.composeencoding
configuration option specify encoding of introduction email.
Signed-off-by: Krzysztof Mazur
---
Documentation/git-send-email.txt | 5
git-send-email.perl | 9 ++-
t/t9001-send-email.sh| 55
3 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3241170..9f09e92 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -126,6 +126,11 @@ The --to option must be repeated for each user you want on
the to list.
+
Note that no attempts whatsoever are made to validate the encoding.
+--compose-encoding=::
+ Specify encoding of compose message. Default is the value of the
+ 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.
++
+
Sending
~~~
diff --git a/git-send-email.perl b/git-send-email.perl
index aea66a0..107e814 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -56,6 +56,7 @@ git send-email [options]
--in-reply-to * Email "In-Reply-To:"
--annotate * Review each patch that will be sent in an
editor.
--compose * Open an editor for introduction.
+--compose-encoding* Encoding to assume for introduction.
--8bit-encoding * Encoding to assume 8bit mails if
undeclared
Sending:
@@ -198,6 +199,7 @@ my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
my ($validate, $confirm);
my (@suppress_cc);
my ($auto_8bit_encoding);
+my ($compose_encoding);
my ($debug_net_smtp) = 0; # Net::SMTP, see send_message()
@@ -231,6 +233,7 @@ my %config_settings = (
"confirm" => \$confirm,
"from" => \$sender,
"assume8bitencoding" => \$auto_8bit_encoding,
+"composeencoding" => \$compose_encoding,
);
my %config_path_settings = (
@@ -315,6 +318,7 @@ my $rc = GetOptions("h" => \$help,
"validate!" => \$validate,
"format-patch!" => \$format_patch,
"8bit-encoding=s" => \$auto_8bit_encoding,
+ "compose-encoding=s" => \$compose_encoding,
"force" => \$force,
);
@@ -638,10 +642,13 @@ EOT
$summary_empty = 0 unless (/^\n$/);
} elsif (/^\n$/) {
$in_body = 1;
+ if (!defined $compose_encoding) {
+ $compose_encoding = "UTF-8";
+ }
if ($need_8bit_cte) {
print $c2 "MIME-Version: 1.0\n",
"Content-Type: text/plain; ",
- "charset=UTF-8\n",
+ "charset=$compose_encoding\n",
"Content-Transfer-Encoding: 8bit\n";
}
} elsif (/^MIME-Version:/i) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 0351228..265ae04 100755
---
Re: git checkout error
Hi Andreas, > > -b requires an argument , which you specify as --no-track > here. is topic, and the rest is interpreted as . > The man page describes --track and --no-track as "options". This is why a reader thinks that they can be specified in any order. It is also very counter-intuitive to think that --no-track is and is topic. This is certainly not what the command does with these data because it creates a new branch whose name is and not --no-track. I proposed a small change that clarifies the syntax, but if you prefer to keep it obscure ... -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Angelo Borsotti writes: > The man page describes --track and --no-track as "options". But the problem you observed is *not* about --track or --no-track. It is about the "-b " option. You used the -b option that requires an argument, and as that argument, you gave a string "--no-track", as if you wanted to create a branch whose name is "--no-track". After these words on the command line are understood, there are two other arguments left on the command line, which is an syntax error as far as "git checkout" is concerned. Again, this is asked-and-answered recently, and http://thread.gmane.org/gmane.comp.version-control.git/204397 has resulted in a leading to b6312c2 (checkout: reorder option handling, 2012-08-30), which is in v1.8.0-rc0 and onwards. You should get an error message that is a lot less confusing: $ git checkout -b --no-track topic remotes/origin/master fatal: '--no-track' is not a valid branch name. -- 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
Fwd: potential path traversal issue in v3 with wild repos
oops; forgot to add the git list earlier. -- Forwarded message -- From: Sitaram Chamarty Date: Wed, Oct 10, 2012 at 5:15 AM Subject: potential path traversal issue in v3 with wild repos To: gitolite , gitolite-annou...@googlegroups.com Cc: Stephane Chazelas Hello all, I'm sorry to say there is a potential path traversal vulnerability in v3. Thanks to Stephane (copied) for finding it and alerting me. Can it affect you? This can only affect you if you are using wild card repos, *and* at least one of your patterns allows the string "../" to match multiple times. (As far as I can tell, this does not affect v2). How badly can it affect you? A malicious user who *also* has the ability to create arbitrary files in, say, /tmp (e.g., he has his own userid on the same box), can compromise the entire "git" user. Otherwise the worst he can do is create arbitrary repos in /tmp. What's the fix? The fix has been pushed, and tagged v3.1. This patch [1] is also backportable to all v3.x tags, in case you are not ready for an actual upgrade (it will have a slight conflict with v3.0 and v3.01 but you should be able to resolve it easily enough; with the others there is no conflict.) My sincere apologies for the fsck-up :( [1]: it's not the top-most commit; be careful if you want to 'git cherry-pick' this to an older tree. -- Sitaram -- Sitaram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone algorithm
On Tue, Oct 9, 2012 at 10:53 PM, Bogdan Cristea wrote: > I have already posted this message on git-us...@googlegroups.com but I have > been > advised to rather use this list. I know that there is a related thread > (http://thread.gmane.org/gmane.comp.version-control.git/207257), but I don't > think that this provides an answer to my question (me too I am on a slow 3G > connection :)) > > I am wondering what algorithm is used by git clone command ? > When cloning from remote repositories, if there is a link failure and > the same command is issued again, the process should be smart enough > to figure out what objects have been already transferred locally and > restart the cloning process from the point it has been interrupted. > As far as I can tell this is not the case, each time I have restarted > the cloning process everything started from the beginning. This is > extremely annoying with slow, unreliable connections. Are there any > ways to cope with this situation or any future plans ? This is not an answer to your question in the general case, sorry... Admins who are managing a site using gitolite can set it up to automatically create and maintain "bundle" files, and allow them to be downloaded using rsync (which, as everyone knows, is resumable), using the same authentication and access rules as gitolite itself. Once you add a couple of lines to the gitolite.conf, it's all pretty much self-maintaining. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git svn clone options
Hi, I tried git svn clone --stdlayout --branch ABC but svn branches were missing (trunk was present), compared to the result of git svn clone --stdlayout Could you clarify --branch option, is it the same as --branches. I thought git clone has --branch option, so I tried this option for svn. Alos, I tried git svn clone --stdlayout --no-checkout It worked without checking out files. but git-svn documentation seems to not mention this option. Could you also tell what options are supported in both git clone and git svn clone, and git clone only options? 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: [PATCH 4/8] wildmatch: remove static variable force_lower_case
On Wed, Oct 10, 2012 at 3:47 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> diff --git a/wildmatch.c b/wildmatch.c >> index 7b64a6b..2382873 100644 >> --- a/wildmatch.c >> +++ b/wildmatch.c >> @@ -11,8 +11,8 @@ >> >> #include >> #include >> -#include >> >> +#include "cache.h" >> #include "wildmatch.h" > > This is wrong; the includes from the system headers should have > been removed in the previous step where the series "integrated" > wildmatch to git, after which point the first include any C source > that is not at the platform-compatibility layer should be cache.h > or git-compat-util.h. Git's ctype does not seem to be complete for wildmatch's use so ctype.h is required. But that can be easily fixed later on. -- 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: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano wrote: > Jeff King writes: > >> I think we just need to have callers of grep_source_init provide us with >> the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is >> where the information is lost. > > Yes. I agree that is the right approach. Passing full path this way means prepare_attr_stack has to walk back to top directory for every files (even in the same directory). If .gitattributes are loaded while git-grep traverses the tree, then it can preload attr once per directory. But Jeff's approach looks simpler. -- 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: [PATCH 4/8] wildmatch: remove static variable force_lower_case
Nguyen Thai Ngoc Duy writes: > Git's ctype does not seem to be complete for wildmatch's use so > ctype.h is required. But that can be easily fixed later on. Until "later on", I cannot even compile the series. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
Nguyen Thai Ngoc Duy writes: > On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano wrote: >> Jeff King writes: >> >>> I think we just need to have callers of grep_source_init provide us with >>> the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is >>> where the information is lost. >> >> Yes. I agree that is the right approach. > > Passing full path this way means prepare_attr_stack has to walk back > to top directory for every files (even in the same directory). If > .gitattributes are loaded while git-grep traverses the tree, then it > can preload attr once per directory. But Jeff's approach looks > simpler. Why can't you do both? That is, to build a full path as you descend, and read per-directory .gitattributes as you go? Confused... -- 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 8/8] Support "**" wildcard in .gitignore and .gitattributes
On Tue, Oct 9, 2012 at 2:57 PM, Michael Haggerty wrote: >> + - A trailing "/**" matches everything inside. For example, >> + "abc/**" is equivalent to "`/abc/`". > > It seems odd that you add a leading slash in this example. I assume > that is because of the rule that a pattern containing a slash is > considered anchored at the current directory. But I find it confusing > because the addition of the leading slash is not part of the rule you > are trying to illustrate here, and is therefore a distraction. I > suggest that you write either > > - A trailing "/**" matches everything inside. For example, > "/abc/**" is equivalent to "`/abc/`". > > or > > - A trailing "/**" matches everything inside. For example, > "abc/**" is equivalent to "`abc/`" (which is also equivalent > to "`/abc/`"). The tricky thing in .gitignore is that the last '/' alone does not imply anchor. So "abc/" means match _directory_ abc anywhere in worktree. So the former is probably better. I should also add a note here (or in gitattributes.txt) about the difference between "/abc/*" and "/abc/**". The former assigns attributes to all files directly under abc (e.g. depth 1), the latter infinite depth. >> + - A slash followed by two consecutive asterisks then a slash >> + matches zero or more directories. For example, "`a/**/b`" >> + matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. >> + >> + - Consecutive asterisks otherwise are treated like normal >> + asterisk wildcards. >> + > > I don't like the last rule. (1) This construct is superfluous; why > wouldn't the user just use a single asterisk? (2) Allowing this > construct means that it could appear in .gitignore files, creating > unnecessary confusion: extrapolating from the other meanings of "**" > users would expect that it would somehow match slashes. (3) It is > conceivable (though admittedly unlikely) that we might want to assign a > distinct meaning to this construct in the future, and accepting it now > as a different way to spell "*" would prevent such a change. > > Perhaps this rule was intended for backwards compatibility? We break backwards compatibility already. Existing "**/" or "/**" patterns now behave differently. > I think it would be preferable to say that other uses of consecutive > asterisks are undefined, and probably make them trigger a warning. Instead of undefined, we can reject the pattern as "broken". I have to check how fnmatch/wildmatch deals with broken patterns (it must do). If it returns a different code for broken patterns, then we can warn users, which is not limited in just "**" breakage. -- 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: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
On Wed, Oct 10, 2012 at 12:33 PM, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >> On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano wrote: >>> Jeff King writes: >>> I think we just need to have callers of grep_source_init provide us with the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is where the information is lost. >>> >>> Yes. I agree that is the right approach. >> >> Passing full path this way means prepare_attr_stack has to walk back >> to top directory for every files (even in the same directory). If >> .gitattributes are loaded while git-grep traverses the tree, then it >> can preload attr once per directory. But Jeff's approach looks >> simpler. > > Why can't you do both? That is, to build a full path as you > descend, and read per-directory .gitattributes as you go? Hm... I need to check attr.c code but I think it means read .gitattributes and prepare attr stack in builtin/grep.c (where we traverse trees) and actually check the attribute in grep_source_load_driver(), much further down the call stack. I'm not sure how we can pass the prepared attr stack down to grep_source_load_driver(). -- 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: [PATCH 4/8] wildmatch: remove static variable force_lower_case
On Wed, Oct 10, 2012 at 12:31 PM, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >> Git's ctype does not seem to be complete for wildmatch's use so >> ctype.h is required. But that can be easily fixed later on. > > Until "later on", I cannot even compile the series. So that's why you noticed this patch :) It builds fine here. I'll fix up and send an update later. -- 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
