[PATCH 05/10] Import wildmatch from rsync
These files are from rsync.git commit f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit before rsync turned GPL-3. All files are imported as-is and no-op. Adaptation is done in a separate patch. rsync.git - git.git lib/wildmatch.[ch] wildmatch.[ch] wildtest.c test-wildmatch.c wildtest.txtt/t3070/wildtest.txt Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t3070/wildtest.txt | 165 +++ test-wildmatch.c | 222 +++ wildmatch.c | 368 +++ wildmatch.h | 6 + 4 files changed, 761 insertions(+) create mode 100644 t/t3070/wildtest.txt create mode 100644 test-wildmatch.c create mode 100644 wildmatch.c create mode 100644 wildmatch.h diff --git a/t/t3070/wildtest.txt b/t/t3070/wildtest.txt new file mode 100644 index 000..42c1678 --- /dev/null +++ b/t/t3070/wildtest.txt @@ -0,0 +1,165 @@ +# Input is in the following format (all items white-space separated): +# +# The first two items are 1 or 0 indicating if the wildmat call is expected to +# succeed and if fnmatch works the same way as wildmat, respectively. After +# that is a text string for the match, and a pattern string. Strings can be +# quoted (if desired) in either double or single quotes, as well as backticks. +# +# MATCH FNMATCH_SAME text to match 'pattern to use' + +# Basic wildmat features +1 1 foofoo +0 1 foobar +1 1 '' +1 1 foo??? +0 1 foo?? +1 1 foo* +1 1 foof* +0 1 foo*f +1 1 foo*foo* +1 1 foobar *ob*a*r* +1 1 aaabababab *ab +1 1 foo* foo\* +0 1 foobar foo\*bar +1 1 f\oo f\\oo +1 1 ball *[al]? +0 1 ten[ten] +1 1 ten**[!te] +0 1 ten**[!ten] +1 1 tent[a-g]n +0 1 tent[!a-g]n +1 1 tont[!a-g]n +1 1 tont[^a-g]n +1 1 a]ba[]]b +1 1 a-ba[]-]b +1 1 a]ba[]-]b +0 1 aaba[]-]b +1 1 aaba[]a-]b +1 1 ] ] + +# Extended slash-matching features +0 1 foo/baz/barfoo*bar +1 1 foo/baz/barfoo**bar +0 1 foo/barfoo?bar +0 1 foo/barfoo[/]bar +0 1 foo/barf[^eiu][^eiu][^eiu][^eiu][^eiu]r +1 1 foo-barf[^eiu][^eiu][^eiu][^eiu][^eiu]r +0 1 foo**/foo +1 1 /foo **/foo +1 1 bar/baz/foo**/foo +0 1 bar/baz/foo*/foo +0 0 foo/bar/baz**/bar* +1 1 deep/foo/bar/baz **/bar/* +0 1 deep/foo/bar/baz/ **/bar/* +1 1 deep/foo/bar/baz/ **/bar/** +0 1 deep/foo/bar **/bar/* +1 1 deep/foo/bar/ **/bar/** +1 1 foo/bar/baz**/bar** +1 1 foo/bar/baz/x */bar/** +0 0 deep/foo/bar/baz/x */bar/** +1 1 deep/foo/bar/baz/x **/bar/*/* + +# Various additional tests +0 1 acrt a[c-c]st +1 1 acrt a[c-c]rt +0 1 ] [!]-] +1 1 a [!]-] +0 1 '' \ +0 1 \ \ +0 1 /\ */\ +1 1 /\ */\\ +1 1 foofoo +1 1 @foo @foo +0 1 foo@foo +1 1 [ab] \[ab] +1 1 [ab] [[]ab] +1 1 [ab] [[:]ab] +0 1 [ab] [[::]ab] +1 1 [ab] [[:digit]ab] +1 1 [ab] [\[:]ab] +1 1 ?a?b \??\?b +1 1 abc\a\b\c +0 1 foo'' +1 1 foo/bar/baz/to **/t[o] + +# Character class tests +1 1 a1B[[:alpha:]][[:digit:]][[:upper:]] +0 1 a [[:digit:][:upper:][:space:]] +1 1 A [[:digit:][:upper:][:space:]] +1 1 1 [[:digit:][:upper:][:space:]] +0 1 1 [[:digit:][:upper:][:spaci:]] +1 1 ' '[[:digit:][:upper:][:space:]] +0 1 . [[:digit:][:upper:][:space:]] +1 1 . [[:digit:][:punct:][:space:]] +1 1 5 [[:xdigit:]] +1 1 f [[:xdigit:]] +1 1 D [[:xdigit:]] +1 1 _ [[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +#1 1 � [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +1 1 [^[:alnum:][:alpha:][:blank:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +1 1 . [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]] +1 1 5
Re: push.default documented in man git-push?
On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano gits...@pobox.com wrote: I would recommend against listing any advice.* in the command manual pages. They are meant to give an advice in cases that are often confusing to new people and are supposed to advise how to turn it off in the message. OK. I think I was surprised that some messages were controlled by advice.* but gave no hints about that and I found that out by other means. I'll check all the advice messages. As far as I can tell, $ git grep -e 'advice\.' Documentation shows the list in config.txt and nothing else, and they do talk about when they are issued, but the reasoning behind them may not be described to a sufficient degree (that is, unless a reader carefully thinks things through, s/he may not be able to figure out why). But I think what we have there is more or less OK. It's about the commands, not the documents. For example I had no idea I could set advice.statusHints to turn off some advice. git status does not say that those messages can be turned off. -- 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: Rebase doesn't restore branch pointer back on out of memory
'format-patch' is failing due to out of memory, and the error not being caught. So 'rebase' thinks 'am' has completed successfully and continue on with cleanup. i.e. move_to_original_branch So the user loses commits from the original head, and have to rely on reflog to return to the original head. Since the exit status of 'format-patch' is not available, we have to use || with 'format-patch' to handle the error. Also, when 'format-patch' fails, the state_dir does not necessarily exist, so I'm putting the 'format-patch-failed' file inside GIT_DIR. Is there a better location to put such a file? The way I handle the error feels a bit bruteforced. Any suggestions on a better way to handle the error? I also thought about separating 'format-patch' and 'am' into two separate commands, and use an intermediate file to store the output of 'format-patch'. But the intermediate file could get very big, so it didn't seem like a good idea. Andrew Wong (1): rebase: Handle cases where format-patch fails git-rebase--am.sh | 37 +++-- 1 file changed, 35 insertions(+), 2 deletions(-) -- 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: upload-pack is slow with lots of refs
Am 10/3/2012 21:41, schrieb Shawn Pearce: On Wed, Oct 3, 2012 at 11:55 AM, Jeff King p...@peff.net wrote: On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Has there been any work on extending the protocol so that the client tells the server what refs it's interested in? I don't think so. It would be hard to do in a backwards-compatible way, because the advertisement is the first thing the server says, before it has negotiated any capabilities with the client at all. That is being discussed but hasn't surfaced on the list. Out of curiosity, how are you thinking about triggering such a new behavior in a backwards-compatible way? Invoke git-upload-pack2, and fall back to reconnecting to start git-upload-pack if it fails? Basically, yes. New clients connect for git-upload-pack2. Over git:// the remote peer will just close the TCP socket with no messages. The client can fallback to git-upload-pack and try again. Over SSH a similar thing will happen in the sense there is no data output from the remote side, so the client can try again. These connections are bidirectional. Upload-pack can just start advertising refs in the v1 way and announce a v2 capability and listen for response in parallel. A v2 capable client can start sending wants or some other signal as soon as it sees the v2 capability. Upload-pack, which was listening for responses in parallel, can interrupt its advertisements and continue with v2 protocol from here. This sounds so simple (not the implementation, of course) - I must be missing something. -- 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
[RFC] rebase: Handle cases where format-patch fails
'format-patch' could fail due to reasons such as out of memory. Such failures are not detected or handled, which causes rebase to incorrectly think that it completed successfully and continue with cleanup. i.e. calling move_to_original_branch Since only the exit status of the last command in the pipeline is available, we rely on || to detect whether 'format-patch' has failed. Also print messages to help user with how to recover from such failures. Signed-off-by: Andrew Wong andrew.k...@gmail.com --- git-rebase--am.sh | 37 +++-- 1 file changed, 35 insertions(+), 2 deletions(-) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index 392ebc9..8dae804 100644 --- a/git-rebase--am.sh +++ b/git-rebase--am.sh @@ -26,10 +26,43 @@ then # makes this easy git cherry-pick --allow-empty $revisions else - git format-patch -k --stdout --full-index --ignore-if-in-upstream \ + ( git format-patch -k --stdout --full-index --ignore-if-in-upstream \ --src-prefix=a/ --dst-prefix=b/ \ - --no-renames $root_flag $revisions | + --no-renames $root_flag $revisions || + echo $? $GIT_DIR/format-patch-failed ) | git am $git_am_opt --rebasing --resolvemsg=$resolvemsg + ret=$? + if test -f $GIT_DIR/format-patch-failed + then + ret=1 + rm -f $GIT_DIR/format-patch-failed + if test -d $state_dir + then + echo + echo 'git format-patch' seems to have failed in the middle of 'git am'. + echo If you continue rebasing, you will likely be losing some commits. + echo It is recommended that you abort rebasing by running: + echo + echo git rebase --abort + echo + else + echo + echo 'git format-patch' seems to have failed before 'git am' started. + echo It is impossible to continue or abort rebasing. + echo You have to use the following to return to your original head: + echo + case $head_name in + refs/*) + echo git checkout $head_name + ;; + *) + echo git checkout $orig_head + ;; + esac + echo + fi + fi + test 0 != $ret false fi move_to_original_branch ret=$? -- 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: [PATCH 5/6] log: pass rev_info to git_log_config()
Junio C Hamano gits...@pobox.com writes: So we would need to do something like: - call git_log_config() first to let diff_context_default updated from the configuration as before. find the values of grep.* defaults at the same time, but stash it away in a separate struct grep_opt (yuck); - call init_revisions() and let it initialize revs-grep_filter and revs-diffopt as before; - copy the grep.* defaults we learned during git_log_config() to revs-grep_filter. which is a bit yucky, but survivable. After thinking about it a bit more, I came to a conclusion that the configuration handling lifted from builtin/grep.c needs a much larger overhaul. The grep_config() function takes one instance of grep_opt as a callback parameter, and populates it by running git_config(). This has three practical implications. - You have to have an instance of grep_opt already when you call the configuration. The codepath under discussion in this thread is a prime example why that arrangement is not always possible. - It is not easy to enhance grep_config() in such a way to make it cascade to other callback functions to grab other variables in one call of git_config(); grep_config() can be cascaded into from other callbacks, but it has to be at the leaf level of a cascade. - If you ever need to use more than one instance of grep_opt, you will have to open and read the configuration file(s) every time you initialize them. The right way to arrange your configuration callback is probably to model it after how diff configuration variables are handled. You call git_config() once, and remember the values you read in set of static variables. Later, whenever you need to instantiate a grep_opt, you initialize it from these static variables. All of the above did not matter back when the code in builtin/grep.c was isolated and the configuration was never meant to be used by other subsystems. But the last two patches in this series do want to break that assumption, so grep_config() needs to be rethought. Luckily, we don't have to have this in the upcoming 1.8.0 release (it is is too late for any topic that is not a regression fix). -- 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: Ignore on commit
From: Andrew Ardill andrew.ard...@gmail.com On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote: ... Similar but not quite; the idea is that you know that there is some code (I'm just talking about files here, so lets ignore hunks for the moment) which is normally checked in but for a period of time you want it ignored. So you don't want it git ignored but at the same time you don't want to see these files in the list of modified files. What is the reason git ignore is no good in this case? Is it simply that you can't see the ignored files in git status, or is it that adding and removing entries to .gitignore is too cumbersome? If it's the latter you could probably put together a simple shell wrapper to automate the task, as otherwise it seems like git ignore does what you need. IIUC the files are already tracked, and a variant of ' git update-index --assume-unchanged' is being requested, so that the command doesn't need to be repeated if they checkuout / swap branches (which assumes I've understood the effect of such an index change correctly) Regards, Andrew Ardill -- -- 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: Ignore on commit
git update-index --assume-unchanged From the help page: --assume-unchanged, --no-assume-unchanged ... This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what .gitignore does for untracked files). Seems like it does everything required. I tested and it correctly hides changes that I want hidden. The only thing I can't see how to do is get git status to show files with the assume unchanged bit set. I think there is no way currently, but that might be a nice addition to make the initial request feature complete. It could show either all files with the bit set, or files with the bit set that have been changed (or this could be configurable). This is indeed the solution outlined in [4] on my original post: http://gitready.com/intermediate/2009/02/18/temporarily-ignoring-files.html The presence in git status is quite important or else one has to change the regular workflow with a second status command. Cheers Marco -- So young, and already so unknown -- Pauli blog: http://mcraveiro.blogspot.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] gitignore: do not do basename match with patterns that have '**'
Am 10/4/2012 9:39, schrieb Nguyễn Thái Ngọc Duy: - - If the pattern does not contain a slash '/', git treats it as - a shell glob pattern and checks for a match against the - pathname relative to the location of the `.gitignore` file - (relative to the toplevel of the work tree if not from a - `.gitignore` file). + - If the pattern does not contain a slash '/' nor '**', git + treats it as a shell glob pattern and checks for a match + against the pathname relative to the location of the + `.gitignore` file (relative to the toplevel of the work tree + if not from a `.gitignore` file). +test_expect_success '** with no slashes test' ' + echo a**f foo=bar .gitattributes + cat \EOF expect +f: foo: unspecified +a/f: foo: bar +a/b/f: foo: bar +a/b/c/f: foo: bar +EOF Should the above .gitattributes match nested paths, such as b/a/c/f? I think it should, because the user can easily say /a**f that nested paths should not be matched. But if it does not match, as your documentation update implies, which options does the user have to match nested paths? Only to add more patterns for each nested directory, such as b/a**f. -- 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
[PATCH] git-svn: keep leading slash when canonicalizing paths (fallback case)
Subversion's svn_dirent_canonicalize() and svn_path_canonicalize()
APIs keep a leading slash in the return value if one was present on
the argument, which can be useful since it allows relative and
absolute paths to be distinguished.
When git-svn's canonicalize_path() learned to use these functions if
available, its semantics changed in the corresponding way. Some new
callers rely on the leading slash --- for example, if the slash is
stripped out then _canonicalize_url_ourselves() will transform
proto://host/path/to/resource to proto://hostpath/to/resource.
Unfortunately the fallback _canonicalize_path_ourselves(), used when
the appropriate SVN APIs are not usable, still follows the old
semantics, so if that code path is exercised then it breaks. Fix it
to follow the new convention.
Noticed by forcing the fallback on and running tests. Without this
patch, t9101.4 fails:
Bad URL passed to RA layer: Unable to open an ra_local session to \
URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\
t9101-git-svn-props/svnrepo' contains unsupported hostname at \
/home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148
With it, the git-svn tests pass again.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi Eric,
Michael G Schwern wrote:
On 2012.7.28 6:55 AM, Jonathan Nieder wrote:
When would this else case trip?
When svn_path_canonicalize() does not exist in the SVN API, presumably because
their SVN is too old.
I accidentally tested this else branch by making the other cases
false. t9101.4 failed as described above, or in other words,
canonicalize_url_ourselves() stripped out a few too many slashes. For
reference:
| sub _canonicalize_url_ourselves {
| my ($url) = @_;
| if ($url =~ m#^([^:]+)://([^/]*)(.*)$#) {
| my ($scheme, $domain, $uri) = ($1, $2,
_canonicalize_url_path(canonicalize_path($3)));
| $url = $scheme://$domain$uri;
| }
| $url;
| }
When $url is http://host/path/to/resource,
$1 = http, $2 = host, $3 = /path/to/resource
canonicalize_path($3) = path/to/resource --- (??)
_canonicalize_url_path(ditto) = path/to/resource
$url = http://hostpath/to/resource;
How about this patch?
perl/Git/SVN/Utils.pm |1 -
1 file changed, 1 deletion(-)
diff --git a/perl/Git/SVN/Utils.pm b/perl/Git/SVN/Utils.pm
index 4bb4dde8..8b8cf375 100644
--- a/perl/Git/SVN/Utils.pm
+++ b/perl/Git/SVN/Utils.pm
@@ -122,7 +122,6 @@ sub _canonicalize_path_ourselves {
$path = _collapse_dotdot($path);
$path =~ s#/$##g;
$path =~ s#^\./## if $dot_slash_added;
- $path =~ s#^/##;
$path =~ s#^\.$##;
return $path;
}
--
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
[PATCH 07/10] wildmatch: fix case-insensitive matching
dowild() does case insensitive matching by lower-casing the text. That
means lower case letters in patterns imply case-insensitive matching,
but upper case means exact matching.
We do not want that subtlety. Lower case pattern too so iwildmatch()
always does what we expect it to do.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
wildmatch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wildmatch.c b/wildmatch.c
index e824eb2..c7f7f9f 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -81,6 +81,8 @@ static int dowild(const uchar *p, const uchar *text,
}
if (force_lower_case ISUPPER(t_ch))
t_ch = tolower(t_ch);
+ if (force_lower_case ISUPPER(p_ch))
+ p_ch = tolower(p_ch);
switch (p_ch) {
case '\\':
/* Literal match with following character. Note that the test
--
1.7.12.1.405.gb727dc9
--
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: grep.patternType
On Wed, Oct 3, 2012 at 6:14 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: * git grep learned to use a non-standard pattern type by default if a configuration variable tells it to. This addition makes git grep -e (integer|buffer) work as expected, when grep.patternType is set to extended. Should this git log --grep=(integer|buffer) also honor the same configuration variable? If not, why not? One more thing. Currently you can say git log -E --grep=(integer|buffer) to ask for the ERE. Should we also support -P to ask for pcre? If not, why not? Answering to myself who has been in tying-loose-ends mode. My answers to these questions are both yes, and I have a neatly lined up series that begins with a small bugfix and then enhancement, but I do not think these do not deserve to in the upcoming release. The topic came too late, and even the fix is for a bug that has been with us for a long time. Yeah, I think that could be useful and consistent. I took a look at the grep situation in the log command briefly when writing the original patch but ended up leaving it as-is as for the time being due to time constraints and the like. But yeah, that behaviour is definitely desirable. I think any commands that work with grep should probably follow suit, for that matter. (Are there others other than log and grep itself...?) -- 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 02/10] attr: avoid strlen() on every match
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/attr.c b/attr.c
index b52efb5..2942bf6 100644
--- a/attr.c
+++ b/attr.c
@@ -277,6 +277,7 @@ static struct match_attr *parse_attr_line(const char *line,
const char *src,
static struct attr_stack {
struct attr_stack *prev;
char *origin;
+ size_t originlen;
unsigned num_matches;
unsigned alloc;
struct match_attr **attrs;
@@ -532,6 +533,7 @@ static void bootstrap_attr_stack(void)
if (!is_bare_repository() || direction == GIT_ATTR_INDEX) {
elem = read_attr(GITATTRIBUTES_FILE, 1);
elem-origin = xstrdup();
+ elem-originlen = 0;
elem-prev = attr_stack;
attr_stack = elem;
debug_push(elem);
@@ -625,7 +627,7 @@ static void prepare_attr_stack(const char *path)
strbuf_addstr(pathbuf, GITATTRIBUTES_FILE);
elem = read_attr(pathbuf.buf, 0);
strbuf_setlen(pathbuf, cp - path);
- elem-origin = strbuf_detach(pathbuf, NULL);
+ elem-origin = strbuf_detach(pathbuf,
elem-originlen);
elem-prev = attr_stack;
attr_stack = elem;
debug_push(elem);
@@ -700,7 +702,7 @@ static int fill(const char *path, int pathlen, struct
attr_stack *stk, int rem)
if (a-is_macro)
continue;
if (path_matches(path, pathlen,
-a-u.pattern, base, strlen(base)))
+a-u.pattern, base, stk-originlen))
rem = fill_one(fill, a, rem);
}
return rem;
--
1.7.12.1.405.gb727dc9
--
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 00/10] nd/wildmatch take 2
The first four patches are ignore/attr cleanups. The following imports wildmatch, nothing new there. The last patch limits allowed syntax to a safe subset: abc/**, **/def and abc/**/def. Nguyễn Thái Ngọc Duy (10): gitignore: make pattern parsing code a separate function attr: avoid strlen() on every match attr: avoid searching for basename on every match attr: more matching optimizations from .gitignore Import wildmatch from rsync wildmatch: remove static variable force_lower_case wildmatch: fix case-insensitive matching Integrate wildmatch to git Support ** in .gitignore and .gitattributes patterns using wildmatch() gitignore: forbid abc**def .gitignore | 1 + Documentation/gitattributes.txt| 2 + Documentation/gitignore.txt| 5 + Makefile | 3 + attr.c | 89 -- dir.c | 82 ++--- dir.h | 3 +- t/t0003-attributes.sh | 22 +++ t/t3001-ls-files-others-exclude.sh | 16 ++ t/t3070-wildmatch.sh | 27 +++ t/t3070/wildtest.txt | 165 + test-wildmatch.c | 208 ++ wildmatch.c| 355 + wildmatch.h| 6 + 14 files changed, 942 insertions(+), 42 deletions(-) create mode 100755 t/t3070-wildmatch.sh create mode 100644 t/t3070/wildtest.txt create mode 100644 test-wildmatch.c create mode 100644 wildmatch.c create mode 100644 wildmatch.h -- 1.7.12.1.405.gb727dc9 -- 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 10/10] gitignore: forbid abc**def
Deep down wildmatch() sees ** as * that can also match slashes. On
the surface, it may be confusing to users as the above pattern can
match abcdef, abcxyzdef, abc/def, abc/x/def,
abc/x/y/def... For now we just forbid it. Users can only do
**/def, abc/** or abc/**/def. The syntax may be re-enabled in
future.
There's a minor problem with this particular approach. ** inside
square brackets are mistaken as the wildcard while they are not. Git
shows a confusing message when users do that.
Note that this patch hides a potential problem that if abc**def is
ever supported, EXC_FLAG_NODIR flag should be turned off or only the
base name is matched against the pattern, which makes no sense.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitignore.txt| 6 --
dir.c | 12 +---
t/t0003-attributes.sh | 5 +
t/t3001-ls-files-others-exclude.sh | 5 +
4 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index eb81d31..ad9fc2f 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -94,8 +94,10 @@ PATTERN FORMAT
Documentation/git.html but not Documentation/ppc/ppc.html
or tools/perf/Documentation/perf.html.
+
-Contrary to fnmatch(3), git matches ** to anything including
-slashes, similar to rsync(1).
+In addition to fnmatch(3) syntax, ** can be used to match one or
+more directories. For example, abc/**/def matches abc/x/def,
+abc/x/y/def, abc/x/y/z/def and so on. ** must be wrapped by
+slashes.
- A leading slash matches the beginning of the pathname.
For example, /{asterisk}.c matches cat-file.c but not
diff --git a/dir.c b/dir.c
index cb78273..f30117f 100644
--- a/dir.c
+++ b/dir.c
@@ -327,12 +327,18 @@ void parse_exclude_pattern(const char **pattern,
len--;
*flags |= EXC_FLAG_MUSTBEDIR;
}
+ *flags |= EXC_FLAG_NODIR;
for (i = 0; i len; i++) {
if (p[i] == '/')
- break;
+ *flags = ~EXC_FLAG_NODIR;
+ if ((p[i] == '*' p[i + 1] == '*'
+(i == 0 || p[i - 1] != '\\'))
+ !((i == 0 || p[i - 1] == '/')
+ (p[i + 2] == '\0' ||
+ p[i + 2] == '/' ||
+ (p[i + 2] == '\\' p[i + 3] == '/'
+ die(_(** in .gitignore or .gitattributes must be
wrapped by slashes));
}
- if (i == len)
- *flags |= EXC_FLAG_NODIR;
*nowildcardlen = simple_length(p);
/*
* we should have excluded the trailing slash from 'p' too,
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 6c3c554..ddeb321 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -249,4 +249,9 @@ EOF
test_line_count = 0 err
'
+test_expect_success '** with no slashes test' '
+ echo a**f foo=bar .gitattributes
+ test_must_fail git check-attr foo -- f
+'
+
test_done
diff --git a/t/t3001-ls-files-others-exclude.sh
b/t/t3001-ls-files-others-exclude.sh
index 67c8bcf..f5c62d0 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -225,4 +225,9 @@ EOF
test_cmp expect actual
'
+
+test_expect_success 'ls-files with ** patterns and no slashes' '
+ test_must_fail git ls-files -o -i --exclude one**a.1
+'
+
test_done
--
1.7.12.1.405.gb727dc9
--
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 08/10] Integrate wildmatch to git
This makes wildmatch.c part of libgit.a and builds test-wildmatch; the
dependency on libpopt in the original has been replaced with the use
of our parse-options. Global variables in test-wildmatch are marked
static to avoid sparse warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Junio C Hamano gits...@pobox.com
---
.gitignore | 1 +
Makefile | 3 ++
t/t3070-wildmatch.sh | 27
test-wildmatch.c | 88 ++--
wildmatch.c | 26 +---
5 files changed, 75 insertions(+), 70 deletions(-)
create mode 100755 t/t3070-wildmatch.sh
diff --git a/.gitignore b/.gitignore
index 68fe464..54b1b3b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -196,6 +196,7 @@
/test-sigchain
/test-subprocess
/test-svn-fe
+/test-wildmatch
/common-cmds.h
*.tar.gz
*.dsc
diff --git a/Makefile b/Makefile
index 26b697d..d6235e6 100644
--- a/Makefile
+++ b/Makefile
@@ -504,6 +504,7 @@ TEST_PROGRAMS_NEED_X += test-sha1
TEST_PROGRAMS_NEED_X += test-sigchain
TEST_PROGRAMS_NEED_X += test-subprocess
TEST_PROGRAMS_NEED_X += test-svn-fe
+TEST_PROGRAMS_NEED_X += test-wildmatch
TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
@@ -676,6 +677,7 @@ LIB_H += userdiff.h
LIB_H += utf8.h
LIB_H += varint.h
LIB_H += walker.h
+LIB_H += wildmatch.h
LIB_H += wt-status.h
LIB_H += xdiff-interface.h
LIB_H += xdiff/xdiff.h
@@ -807,6 +809,7 @@ LIB_OBJS += utf8.o
LIB_OBJS += varint.o
LIB_OBJS += version.o
LIB_OBJS += walker.o
+LIB_OBJS += wildmatch.o
LIB_OBJS += wrapper.o
LIB_OBJS += write_or_die.o
LIB_OBJS += ws.o
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
new file mode 100755
index 000..c4da26c
--- /dev/null
+++ b/t/t3070-wildmatch.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+test_description='wildmatch tests'
+
+. ./test-lib.sh
+
+test_wildmatch() {
+test_expect_success wildmatch $*
+ test-wildmatch $* ../t3070/wildtest.txt actual
+ echo 'No wildmatch errors found.' expected
+ test_cmp expected actual
+
+}
+
+test_wildmatch -x1
+test_wildmatch -x1 -e1
+test_wildmatch -x1 -else
+test_wildmatch -x2
+test_wildmatch -x2 -ese
+test_wildmatch -x3
+test_wildmatch -x3 -e1
+test_wildmatch -x4
+test_wildmatch -x4 -e2e
+test_wildmatch -x5
+test_wildmatch -x5 -es
+
+test_done
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 88585c2..bb726c8 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -19,34 +19,38 @@
/*#define COMPARE_WITH_FNMATCH*/
-#define WILD_TEST_ITERATIONS
-#include lib/wildmatch.c
+#include cache.h
+#include parse-options.h
+#include wildmatch.h
-#include popt.h
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 1024
+#endif
+#ifdef NO_STRLCPY
+#include compat/strlcpy.c
+#define strlcpy gitstrlcpy
+#endif
#ifdef COMPARE_WITH_FNMATCH
#include fnmatch.h
-int fnmatch_errors = 0;
+static int fnmatch_errors = 0;
#endif
-int wildmatch_errors = 0;
-char number_separator = ',';
+static int wildmatch_errors = 0;
typedef char bool;
-int output_iterations = 0;
-int explode_mod = 0;
-int empties_mod = 0;
-int empty_at_start = 0;
-int empty_at_end = 0;
-
-static struct poptOption long_options[] = {
- /* longName, shortName, argInfo, argPtr, value, descrip, argDesc */
- {iterations, 'i', POPT_ARG_NONE, output_iterations, 0, 0, 0},
- {empties,'e', POPT_ARG_STRING, 0, 'e', 0, 0},
- {explode,'x', POPT_ARG_INT,explode_mod, 0, 0, 0},
- {0,0,0,0, 0, 0, 0}
+static int explode_mod = 0;
+static int empties_mod = 0;
+static int empty_at_start = 0;
+static int empty_at_end = 0;
+static char *empties;
+
+static struct option options[] = {
+ OPT_STRING('e', empties, empties, , ),
+ OPT_INTEGER('x', explode, explode_mod, ),
+ OPT_END(),
};
/* match just at the start of string (anchored tests) */
@@ -100,51 +104,33 @@ run_test(int line, bool matches,
fnmatch_errors++;
}
#endif
-if (output_iterations) {
- printf(%d: \%s\ iterations = %d\n, line, pattern,
- wildmatch_iteration_count);
-}
}
int
main(int argc, char **argv)
{
char buf[2048], *s, *string[2], *end[2];
-const char *arg;
FILE *fp;
-int opt, line, i, flag[2];
-poptContext pc = poptGetContext(wildtest, argc, (const char**)argv,
- long_options, 0);
-
-while ((opt = poptGetNextOpt(pc)) != -1) {
- switch (opt) {
- case 'e':
- arg = poptGetOptArg(pc);
- empties_mod = atoi(arg);
- if (strchr(arg, 's'))
- empty_at_start = 1;
- if (strchr(arg, 'e'))
- empty_at_end = 1;
- if (!explode_mod)
- explode_mod = 1024;
- break;
- default:
- fprintf(stderr, %s: %s\n,
- poptBadOption(pc, POPT_BADOPTION_NOALIAS),
- poptStrerror(opt));
- exit(1);
- }
+
Fwd: git-completion of branches containing @ in their name
Hello, When I try to complete a branch name containing @, it doesn't expand as expected. Running git on Windows 7. $ git --version git version 1.7.11.msysgit.1 $ git branch * master master@feature If I write $ git checkout master@ and press tab, the above expands to $ git checkout mastermaster@feature -- Børge Bjørnli Nygård -- 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 01/10] gitignore: make pattern parsing code a separate function
This function can later be reused by attr.c. Also turn to_exclude
field into a flag.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
If we go with glob-regex conversion way, this is where we could
rewrite the pattern (and set EXC_FLAG_REGEX).
dir.c | 71 ++-
dir.h | 2 +-
2 files changed, 50 insertions(+), 23 deletions(-)
diff --git a/dir.c b/dir.c
index 240bf0c..cd13920 100644
--- a/dir.c
+++ b/dir.c
@@ -308,42 +308,69 @@ static int no_wildcard(const char *string)
return string[simple_length(string)] == '\0';
}
+static void parse_exclude_pattern(const char **pattern,
+ int *patternlen,
+ int *flags,
+ int *nowildcardlen)
+{
+ const char *p = *pattern;
+ size_t i, len;
+
+ *flags = 0;
+ if (*p == '!') {
+ *flags |= EXC_FLAG_NEGATIVE;
+ p++;
+ }
+ len = strlen(p);
+ if (len p[len - 1] == '/') {
+ len--;
+ *flags |= EXC_FLAG_MUSTBEDIR;
+ }
+ for (i = 0; i len; i++) {
+ if (p[i] == '/')
+ break;
+ }
+ if (i == len)
+ *flags |= EXC_FLAG_NODIR;
+ *nowildcardlen = simple_length(p);
+ /*
+* we should have excluded the trailing slash from 'p' too,
+* but that's one more allocation. Instead just make sure
+* nowildcardlen does not exceed real patternlen
+*/
+ if (*nowildcardlen len)
+ *nowildcardlen = len;
+ if (*p == '*' no_wildcard(p + 1))
+ *flags |= EXC_FLAG_ENDSWITH;
+ *pattern = p;
+ *patternlen = len;
+}
+
void add_exclude(const char *string, const char *base,
int baselen, struct exclude_list *which)
{
struct exclude *x;
- size_t len;
- int to_exclude = 1;
- int flags = 0;
+ int patternlen;
+ int flags;
+ int nowildcardlen;
- if (*string == '!') {
- to_exclude = 0;
- string++;
- }
- len = strlen(string);
- if (len string[len - 1] == '/') {
+ parse_exclude_pattern(string, patternlen, flags, nowildcardlen);
+ if (flags EXC_FLAG_MUSTBEDIR) {
char *s;
- x = xmalloc(sizeof(*x) + len);
+ x = xmalloc(sizeof(*x) + patternlen + 1);
s = (char *)(x+1);
- memcpy(s, string, len - 1);
- s[len - 1] = '\0';
- string = s;
+ memcpy(s, string, patternlen);
+ s[patternlen] = '\0';
x-pattern = s;
- flags = EXC_FLAG_MUSTBEDIR;
} else {
x = xmalloc(sizeof(*x));
x-pattern = string;
}
- x-to_exclude = to_exclude;
- x-patternlen = strlen(string);
+ x-patternlen = patternlen;
+ x-nowildcardlen = nowildcardlen;
x-base = base;
x-baselen = baselen;
x-flags = flags;
- if (!strchr(string, '/'))
- x-flags |= EXC_FLAG_NODIR;
- x-nowildcardlen = simple_length(string);
- if (*string == '*' no_wildcard(string+1))
- x-flags |= EXC_FLAG_ENDSWITH;
ALLOC_GROW(which-excludes, which-nr + 1, which-alloc);
which-excludes[which-nr++] = x;
}
@@ -518,7 +545,7 @@ int excluded_from_list(const char *pathname,
for (i = el-nr - 1; 0 = i; i--) {
struct exclude *x = el-excludes[i];
const char *name, *exclude = x-pattern;
- int to_exclude = x-to_exclude;
+ int to_exclude = x-flags EXC_FLAG_NEGATIVE ? 0 : 1;
int namelen, prefix = x-nowildcardlen;
if (x-flags EXC_FLAG_MUSTBEDIR) {
diff --git a/dir.h b/dir.h
index 893465a..41ea32d 100644
--- a/dir.h
+++ b/dir.h
@@ -11,6 +11,7 @@ struct dir_entry {
#define EXC_FLAG_NODIR 1
#define EXC_FLAG_ENDSWITH 4
#define EXC_FLAG_MUSTBEDIR 8
+#define EXC_FLAG_NEGATIVE 16
struct exclude_list {
int nr;
@@ -21,7 +22,6 @@ struct exclude_list {
int nowildcardlen;
const char *base;
int baselen;
- int to_exclude;
int flags;
} **excludes;
};
--
1.7.12.1.405.gb727dc9
--
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 04/10] attr: more matching optimizations from .gitignore
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch adds those optimizations to .gitattributes. Basically it
tries to avoid fnmatch/wildmatch in favor of strncmp as much as
possible.
There are two syntaxes that .gitignore supports but .gitattributes
does not: negative patterns and directory matching. They have never
worked and whether they will is up for future discussion. Meanwhile
make a note in the document and reject such patterns.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitattributes.txt | 2 ++
attr.c | 68 ++---
dir.c | 8 ++---
dir.h | 1 +
4 files changed, 64 insertions(+), 15 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index e16f3e1..702b8c1 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -56,6 +56,8 @@ When more than one pattern matches the path, a later line
overrides an earlier line. This overriding is done per
attribute. The rules how the pattern matches paths are the
same as in `.gitignore` files; see linkgit:gitignore[5].
+Unlike `.gitignore`, negative patterns are not supported.
+Patterns that match directories are also not supported.
When deciding what attributes are assigned to a path, git
consults `$GIT_DIR/info/attributes` file (which has the highest
diff --git a/attr.c b/attr.c
index aeac564..1aa058e 100644
--- a/attr.c
+++ b/attr.c
@@ -115,6 +115,13 @@ struct attr_state {
const char *setto;
};
+struct pattern {
+ const char *pattern;
+ int patternlen;
+ int nowildcardlen;
+ int flags; /* EXC_FLAG_* */
+};
+
/*
* One rule, as from a .gitattributes file.
*
@@ -131,7 +138,7 @@ struct attr_state {
*/
struct match_attr {
union {
- char *pattern;
+ struct pattern pat;
struct git_attr *attr;
} u;
char is_macro;
@@ -241,9 +248,18 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
if (is_macro)
res-u.attr = git_attr_internal(name, namelen);
else {
- res-u.pattern = (char *)(res-state[num_attr]);
- memcpy(res-u.pattern, name, namelen);
- res-u.pattern[namelen] = 0;
+ char *p = (char *)(res-state[num_attr]);
+ memcpy(p, name, namelen);
+ p[namelen] = 0;
+ res-u.pat.pattern = p;
+ parse_exclude_pattern(res-u.pat.pattern,
+ res-u.pat.patternlen,
+ res-u.pat.flags,
+ res-u.pat.nowildcardlen);
+ if (res-u.pat.flags EXC_FLAG_NEGATIVE)
+ die(_(Negative patterns are not supported in git
attributes));
+ if (res-u.pat.flags EXC_FLAG_MUSTBEDIR)
+ die(_(Directory patterns are not supported in git
attributes));
}
res-is_macro = is_macro;
res-num_attr = num_attr;
@@ -645,25 +661,55 @@ static void prepare_attr_stack(const char *path)
static int path_matches(const char *pathname, int pathlen,
const char *basename,
- const char *pattern,
+ const struct pattern *pat,
const char *base, int baselen)
{
- if (!strchr(pattern, '/')) {
+ const char *pattern = pat-pattern;
+ int prefix = pat-nowildcardlen;
+ const char *name;
+ int namelen;
+
+ if (pat-flags EXC_FLAG_NODIR) {
+ if (prefix == pat-patternlen
+ !strcmp_icase(pattern, basename))
+ return 1;
+
+ if (pat-flags EXC_FLAG_ENDSWITH
+ pat-patternlen - 1 = pathlen
+ !strcmp_icase(pattern + 1, pathname +
+ pathlen - pat-patternlen + 1))
+ return 1;
+
return (fnmatch_icase(pattern, basename, 0) == 0);
}
/*
* match with FNM_PATHNAME; the pattern has base implicitly
* in front of it.
*/
- if (*pattern == '/')
+ if (*pattern == '/') {
pattern++;
+ prefix--;
+ }
+
+ /*
+* note: unlike excluded_from_list, baselen here does not
+* contain the trailing slash
+*/
+
if (pathlen baselen ||
(baselen pathname[baselen] != '/') ||
strncmp(pathname, base, baselen))
return 0;
- if (baselen != 0)
- baselen++;
- return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+
+
[PATCH 06/10] wildmatch: remove static variable force_lower_case
One place less to worry about thread safety
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
wildmatch.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index f3a1731..e824eb2 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -57,11 +57,10 @@
int wildmatch_iteration_count;
#endif
-static int force_lower_case = 0;
-
/* Match pattern p against the a virtually-joined string consisting
* of text and any strings in array a. */
-static int dowild(const uchar *p, const uchar *text, const uchar*const *a)
+static int dowild(const uchar *p, const uchar *text,
+ const uchar*const *a, int force_lower_case)
{
uchar p_ch;
@@ -121,7 +120,7 @@ static int dowild(const uchar *p, const uchar *text, const
uchar*const *a)
t_ch = *text;
continue;
}
- if ((matched = dowild(p, text, a)) != FALSE) {
+ if ((matched = dowild(p, text, a, force_lower_case)) != FALSE) {
if (!special || matched != ABORT_TO_STARSTAR)
return matched;
} else if (!special t_ch == '/')
@@ -291,7 +290,7 @@ int wildmatch(const char *pattern, const char *text)
#ifdef WILD_TEST_ITERATIONS
wildmatch_iteration_count = 0;
#endif
-return dowild((const uchar*)pattern, (const uchar*)text, nomore) == TRUE;
+return dowild((const uchar*)pattern, (const uchar*)text, nomore, 0) ==
TRUE;
}
/* Match the pattern against the forced-to-lower-case text string. */
@@ -302,9 +301,7 @@ int iwildmatch(const char *pattern, const char *text)
#ifdef WILD_TEST_ITERATIONS
wildmatch_iteration_count = 0;
#endif
-force_lower_case = 1;
-ret = dowild((const uchar*)pattern, (const uchar*)text, nomore) == TRUE;
-force_lower_case = 0;
+ret = dowild((const uchar*)pattern, (const uchar*)text, nomore, 1) == TRUE;
return ret;
}
@@ -331,7 +328,7 @@ int wildmatch_array(const char *pattern, const char*const
*texts, int where)
if (!text)
return FALSE;
-if ((matched = dowild(p, text, a)) != TRUE where 0
+if ((matched = dowild(p, text, a, 0)) != TRUE where 0
matched != ABORT_ALL) {
while (1) {
if (*text == '\0') {
@@ -339,7 +336,7 @@ int wildmatch_array(const char *pattern, const char*const
*texts, int where)
return FALSE;
continue;
}
- if (*text++ == '/' (matched = dowild(p, text, a)) != FALSE
+ if (*text++ == '/' (matched = dowild(p, text, a, 0)) != FALSE
matched != ABORT_TO_STARSTAR)
break;
}
--
1.7.12.1.405.gb727dc9
--
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 03/10] attr: avoid searching for basename on every match
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/attr.c b/attr.c
index 2942bf6..aeac564 100644
--- a/attr.c
+++ b/attr.c
@@ -644,13 +644,11 @@ static void prepare_attr_stack(const char *path)
}
static int path_matches(const char *pathname, int pathlen,
+ const char *basename,
const char *pattern,
const char *base, int baselen)
{
if (!strchr(pattern, '/')) {
- /* match basename */
- const char *basename = strrchr(pathname, '/');
- basename = basename ? basename + 1 : pathname;
return (fnmatch_icase(pattern, basename, 0) == 0);
}
/*
@@ -692,7 +690,8 @@ static int fill_one(const char *what, struct match_attr *a,
int rem)
return rem;
}
-static int fill(const char *path, int pathlen, struct attr_stack *stk, int rem)
+static int fill(const char *path, int pathlen, const char *basename,
+ struct attr_stack *stk, int rem)
{
int i;
const char *base = stk-origin ? stk-origin : ;
@@ -701,7 +700,7 @@ static int fill(const char *path, int pathlen, struct
attr_stack *stk, int rem)
struct match_attr *a = stk-attrs[i];
if (a-is_macro)
continue;
- if (path_matches(path, pathlen,
+ if (path_matches(path, pathlen, basename,
a-u.pattern, base, stk-originlen))
rem = fill_one(fill, a, rem);
}
@@ -740,15 +739,19 @@ static void collect_all_attrs(const char *path)
{
struct attr_stack *stk;
int i, pathlen, rem;
+ const char *basename;
prepare_attr_stack(path);
for (i = 0; i attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
+ basename = strrchr(path, '/');
+ basename = basename ? basename + 1 : path;
+
pathlen = strlen(path);
rem = attr_nr;
for (stk = attr_stack; 0 rem stk; stk = stk-prev)
- rem = fill(path, pathlen, stk, rem);
+ rem = fill(path, pathlen, basename, stk, rem);
}
int git_check_attr(const char *path, int num, struct git_attr_check *check)
--
1.7.12.1.405.gb727dc9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug report
There's a problem using git with files having cyrillic 'й' in their name, git just can't track them. uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git version: 1.7.12.1 (from macports) Steps to reproduce: - git init - touch test_й - git status (should be untracked files present) - git add test_й - git status # Untracked files: # (use git add file... to include in what will be committed) # # test_\320\270\314\206 nothing added to commit but untracked files present (use git add to track) Could this be helped somehow?-- 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 05/10] Import wildmatch from rsync
These files are from rsync.git commit f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit before rsync turned GPL-3. However: diff --git a/test-wildmatch.c b/test-wildmatch.c [...] + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. -- \\// Peter - http://www.softwolves.pp.se/ -- 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 Fri, 5 Oct 2012 14:13:49 +0400 Муковников Михаил m.mukovni...@gmail.com wrote: There's a problem using git with files having cyrillic 'й' in their name, git just can't track them. uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git version: 1.7.12.1 (from macports) Steps to reproduce: - git init - touch test_й - git status (should be untracked files present) - git add test_й - git status # Untracked files: # (use git add file... to include in what will be committed) # # test_\320\270\314\206 nothing added to commit but untracked files present (use git add to track) Could this be helped somehow?-- What this? If you mean displaying escapes for UTF-8 bytes representing that letter й, then try setting core.quotepath to false for this repository and see if that helps. More info can be found in the git-config manual page. -- 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
Konstantin Khomoutov flatw...@users.sourceforge.net writes: On Fri, 5 Oct 2012 14:13:49 +0400 Муковников Михаил m.mukovni...@gmail.com wrote: There's a problem using git with files having cyrillic 'й' in their name, git just can't track them. uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git version: 1.7.12.1 (from macports) Steps to reproduce: - git init - touch test_й - git status (should be untracked files present) - git add test_й - git status # Untracked files: # (use git add file... to include in what will be committed) # #test_\320\270\314\206 nothing added to commit but untracked files present (use git add to track) Could this be helped somehow?-- What this? If you mean displaying escapes for UTF-8 bytes representing that letter й, then try setting core.quotepath to false for this repository and see if that helps. Notice the 'git add test_й'. The problem is that git reports it as untracked. Михаил, is this the whole output or do you also see a differently-escaped version of the filename under tracked files? Does this problem not show up if you use 'git add -A' or 'git add .' instead of typing the name? If so, this happens because HFS+ stores and reports names differently than the way we told it to store it, so git sees a different set of bytes than what it's expecting and considers it a different file. With a recent version of git, you can set the core.precomposeunicode config setting to true, which deals with this situation. This tells git to transform the data it gets from the filesystem to the format that everyone else uses, which helps not only this, but also the 'git add .' case, so git stores the filename in the format the same way that other OSs expect to find. 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
Re: Bug report
Hey, Konstantin! Thanks for your reply. My bad, I described the problem not very well. I don't mind displaying escapes etc. (core.quotepath just makes \320\270\314\206 be й and that's it), the problem is that git cannot track files with cyrillic й in their name. I created a file, added it but git writes it's still untracked, and it seems there's no way to track it. 05.10.2012, в 14:32, Konstantin Khomoutov flatw...@users.sourceforge.net написал(а): On Fri, 5 Oct 2012 14:13:49 +0400 Муковников Михаил m.mukovni...@gmail.com wrote: There's a problem using git with files having cyrillic 'й' in their name, git just can't track them. uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git version: 1.7.12.1 (from macports) Steps to reproduce: - git init - touch test_й - git status (should be untracked files present) - git add test_й - git status # Untracked files: # (use git add file... to include in what will be committed) # #test_\320\270\314\206 nothing added to commit but untracked files present (use git add to track) Could this be helped somehow?-- What this? If you mean displaying escapes for UTF-8 bytes representing that letter й, then try setting core.quotepath to false for this repository and see if that helps. More info can be found in the git-config manual page. -- 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
Carlos, thank you very much, core.precomposeunicode works just like you said. And you're right, it seems the problem is in HFS+, 'git add .' worked as well, so did even 'git add test_*'. The problem seems solved. 05.10.2012, в 14:47, c...@elego.de (Carlos Martín Nieto) написал(а): Konstantin Khomoutov flatw...@users.sourceforge.net writes: On Fri, 5 Oct 2012 14:13:49 +0400 Муковников Михаил m.mukovni...@gmail.com wrote: There's a problem using git with files having cyrillic 'й' in their name, git just can't track them. uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git version: 1.7.12.1 (from macports) Steps to reproduce: - git init - touch test_й - git status (should be untracked files present) - git add test_й - git status # Untracked files: # (use git add file... to include in what will be committed) # # test_\320\270\314\206 nothing added to commit but untracked files present (use git add to track) Could this be helped somehow?-- What this? If you mean displaying escapes for UTF-8 bytes representing that letter й, then try setting core.quotepath to false for this repository and see if that helps. Notice the 'git add test_й'. The problem is that git reports it as untracked. Михаил, is this the whole output or do you also see a differently-escaped version of the filename under tracked files? Does this problem not show up if you use 'git add -A' or 'git add .' instead of typing the name? If so, this happens because HFS+ stores and reports names differently than the way we told it to store it, so git sees a different set of bytes than what it's expecting and considers it a different file. With a recent version of git, you can set the core.precomposeunicode config setting to true, which deals with this situation. This tells git to transform the data it gets from the filesystem to the format that everyone else uses, which helps not only this, but also the 'git add .' case, so git stores the filename in the format the same way that other OSs expect to find. 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
Re: [PATCH 05/10] Import wildmatch from rsync
On Fri, Oct 5, 2012 at 5:30 PM, Peter Krefting pe...@softwolves.pp.se wrote: These files are from rsync.git commit f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit before rsync turned GPL-3. However: diff --git a/test-wildmatch.c b/test-wildmatch.c [...] + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. A copy mistake. I probably did not look closely at this file as it's not the main source, we could even rewrite it with little effort. Will update with GPL2 version next round. -- 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 5/6] gitignore: do not do basename match with patterns that have '**'
On Fri, Oct 5, 2012 at 2:01 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 10/4/2012 9:39, schrieb Nguyễn Thái Ngọc Duy: - - If the pattern does not contain a slash '/', git treats it as - a shell glob pattern and checks for a match against the - pathname relative to the location of the `.gitignore` file - (relative to the toplevel of the work tree if not from a - `.gitignore` file). + - If the pattern does not contain a slash '/' nor '**', git + treats it as a shell glob pattern and checks for a match + against the pathname relative to the location of the + `.gitignore` file (relative to the toplevel of the work tree + if not from a `.gitignore` file). I think in the latest round, we forbid this case (i.e. a/**, **/b and a/**/b are ok, but a**b is not), exactly because it's hard to define how it should do. Thanks for another example. +test_expect_success '** with no slashes test' ' + echo a**f foo=bar .gitattributes + cat \EOF expect +f: foo: unspecified +a/f: foo: bar +a/b/f: foo: bar +a/b/c/f: foo: bar +EOF Should the above .gitattributes match nested paths, such as b/a/c/f? I think it should, because the user can easily say /a**f that nested paths should not be matched. The user can also say **/a/**f to match b/a/c/f. -- 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: What's cooking in git.git (Oct 2012, #01; Tue, 2)
Junio C Hamano gits...@pobox.com writes: When we require x/**/y, I think we still want it to match x/y. FWIW, in bash (+extglob), ksh and zsh it doesn't. 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: What's cooking in git.git (Oct 2012, #01; Tue, 2)
Andreas Schwab sch...@linux-m68k.org writes: Junio C Hamano gits...@pobox.com writes: When we require x/**/y, I think we still want it to match x/y. FWIW, in bash (+extglob), ksh and zsh it doesn't. You're right about bash, but I see the opposite for zsh and ksh: zsh$ echo x/**/y x/y x/z/y ksh$ echo x/**/y x/y x/z/y (didn't check the doc so see whether this was configurable, but I've set HOME=/ when launching the shell to disable my own configuration) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)
On Thu, Oct 04, 2012 at 09:39:02AM -0700, Junio C Hamano wrote:
Assuming that we do want to match x/y with x/**/y, I suspect
that '**' matches anything including a slash would not give us
that semantics. Is it something we can easily fix in the wildmatch
code?
Something like this may suffice. Lightly tested with git add -n.
Reading the code, I think we can even distinguish match zero or more
directories and match one or more directories with /**/ and maybe
/***/. Right now **, ***, ... are the same. So are /**/, /***/,
//...
-- 8 --
diff --git a/wildmatch.c b/wildmatch.c
index f153f8a..81eadc8 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -98,8 +98,12 @@ static int dowild(const uchar *p, const uchar *text,
continue;
case '*':
if (*++p == '*') {
+ int slashstarstar = p[-2] == '/';
while (*++p == '*') {}
special = TRUE;
+ if (slashstarstar *p == '/'
+ dowild(p + 1, text, a, force_lower_case) == TRUE)
+ return TRUE;
} else
special = FALSE;
if (*p == '\0') {
-- 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: Ignore on commit
Marco, Similar but not quite; the idea is that you know that there is some code (I'm just talking about files here, so lets ignore hunks for the moment) which is normally checked in but for a period of time you want it ignored. Got it thanks! Would be useful some time indeed. -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B -- 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
Fw: [git-users] How do I git-push to an FTP server?
On the git-users mailing list we're trying someone to help with running `git push` over FTP. That person is runnig Git 1.7.9.5 on Ubuntu 12.04. Below is the trace captured while trying to perform such a faulty push. The oddity (in my eyes) is that after uploading the files, Git executes `git http-push` which manual page does not mention FTP at all. So I'd like to ask experts on Git transports for any advice in this situation. Begin forwarded message: Date: Fri, 5 Oct 2012 05:07:24 -0700 (PDT) From: August Karlstrom fusio...@gmail.com To: git...@googlegroups.com Cc: August Karlstrom fusio...@gmail.com Subject: Re: [git-users] How do I git-push to an FTP server? Den fredagen den 5:e oktober 2012 kl. 11:38:43 UTC+2 skrev Konstantin Khomoutov: On Fri, 5 Oct 2012 01:24:21 -0700 (PDT) August Karlstrom fusio...@gmail.com javascript: wrote: I get the following error when I run `git push' in a repository called test: error: Cannot access URL ftp://my-ftp-server/git/test.git/, return code 3 fatal: git-http-push failed This is after having successfully cloned the repository from the address above. Try to run your command while having set GIT_TRACE=1 and GIT_CURL_VERBOSE=1, like $ GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push and post the results here (if you will fail to infer the cause from its output by yourself). Thanks for the input, Konstantin. Below is the output (with identifying info removed). I can't see what caused Uploading to a URL without a file name at the end. $ GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push trace: built-in: git 'push' trace: run_command: 'git-remote-ftp' 'origin' 'ftp://my-ftp-server/git/test.git' * About to connect() to my-ftp-server port 21 (#0) * Trying my-ftp-ip... * Connected to my-ftp-server (my-ftp-ip) port 21 (#0) 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 6 of 400 allowed. 220-Local time is now 11:23. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 15 minutes of inactivity. USER my-username 331 User my-username OK. Password required PASS my-password 230-User my-username has group access to: my-group 230 OK. Current restricted directory is / PWD 257 / is your current location * Entry path is '/' CWD git 250 OK. Current directory is /git CWD test.git 250 OK. Current directory is /git/test.git CWD info 250 OK. Current directory is /git/test.git/info EPSV * Connect data stream passively 500 Unknown command * disabling EPSV usage PASV 227 Entering Passive Mode ([not shown]) * Trying my-ftp-ip... * Connecting to my-ftp-ip (my-ftp-ip) port 63983 TYPE I 200 TYPE is now 8-bit binary SIZE refs 213 59 RETR refs 150 Accepted data connection * Maxdownload = -1 * Getting file with size: 59 * Remembering we are in dir git/test.git/info/ 226-File successfully transferred 226 0.000 seconds (measured here), 1.34 Mbytes per second * Connection #0 to host my-ftp-server left intact * Re-using existing connection! (#0) with host my-ftp-server * Connected to my-ftp-server (my-ftp-ip) port 21 (#0) CWD / 250 OK. Current directory is / CWD git 250 OK. Current directory is /git CWD test.git 250 OK. Current directory is /git/test.git PASV * Connect data stream passively 227 Entering Passive Mode ([not shown]) * Trying my-ftp-ip... * Connecting to my-ftp-ip (my-ftp-ip) port 63462 SIZE HEAD 213 23 RETR HEAD 150 Accepted data connection * Maxdownload = -1 * Getting file with size: 23 * Remembering we are in dir git/test.git/ 226-File successfully transferred 226 0.000 seconds (measured here), 0.63 Mbytes per second * Connection #0 to host my-ftp-server left intact trace: run_command: 'http-push' '--helper-status' 'ftp://my-ftp-server/git/test.git/' 'refs/heads/master:refs/heads/master' trace: exec: 'git' 'http-push' '--helper-status' 'ftp://my-ftp-server/git/test.git/' 'refs/heads/master:refs/heads/master' trace: exec: 'git-http-push' '--helper-status' 'ftp://my-ftp-server/git/test.git/' 'refs/heads/master:refs/heads/master' trace: run_command: 'git-http-push' '--helper-status' 'ftp://my-ftp-server/git/test.git/' 'refs/heads/master:refs/heads/master' * About to connect() to my-ftp-server port 21 (#0) * Trying my-ftp-ip... * Connected to my-ftp-server (my-ftp-ip) port 21 (#0) 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 7 of 400 allowed. 220-Local time is now 11:23. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 15 minutes of inactivity. USER my-username 331 User my-username OK. Password required PASS my-password 230-User my-username has group access to: my-group 230 OK. Current restricted directory is / PWD 257 / is your current location * Entry path is '/' * Uploading to a URL without a file name! * Closing connection #0 error: Cannot access URL
Re: Fw: [git-users] How do I git-push to an FTP server?
On the git-users mailing list we're trying someone to help with running `git push` over FTP. That person is runnig Git 1.7.9.5 on Ubuntu 12.04. I don't think vanilla git supports pushing over ftp. There are plugins like https://github.com/resmo/git-ftp tho. Philippe -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)
Matthieu Moy matthieu@grenoble-inp.fr writes: Andreas Schwab sch...@linux-m68k.org writes: Junio C Hamano gits...@pobox.com writes: When we require x/**/y, I think we still want it to match x/y. FWIW, in bash (+extglob), ksh and zsh it doesn't. You're right about bash, but I see the opposite for zsh and ksh: zsh$ echo x/**/y x/y x/z/y ksh$ echo x/**/y x/y x/z/y Looks like this is different between filename expansion and case pattern matching (I only tested the latter). 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
git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
What I did: - New file images/coins.asy ~~- 'git add images/coins.asy' - Started adding new stuff to fg.tex - Noticed a old bug in fg.tex, fixed that one - Did 'git -pm Some message' and selected just the bugfix But git created a commit _including_ the new file. Tried to go back: - 'git reset HEAD^' Now the new file isn't staged anymore What I expected to happen: - Only the explicitly selected chunks commited - No losing staged changes -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- 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: Fw: [git-users] How do I git-push to an FTP server?
On Fri, Oct 5, 2012 at 3:46 PM, Philippe Vaucher philippe.vauc...@gmail.com wrote: On the git-users mailing list we're trying someone to help with running `git push` over FTP. That person is runnig Git 1.7.9.5 on Ubuntu 12.04. I don't think vanilla git supports pushing over ftp. At least according to the documentation[1], Git natively supports [...] ftp. This could need some clarification if pushing over ftp is not supported. [1] http://www.kernel.org/pub/software/scm/git/docs/git-push.html#URLS -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] log: pass rev_info to git_log_config()
On Thu, Oct 04, 2012 at 09:16:14PM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: So we would need to do something like: - call git_log_config() first to let diff_context_default updated from the configuration as before. find the values of grep.* defaults at the same time, but stash it away in a separate struct grep_opt (yuck); - call init_revisions() and let it initialize revs-grep_filter and revs-diffopt as before; - copy the grep.* defaults we learned during git_log_config() to revs-grep_filter. which is a bit yucky, but survivable. After thinking about it a bit more, I came to a conclusion that the configuration handling lifted from builtin/grep.c needs a much larger overhaul. [...] The right way to arrange your configuration callback is probably to model it after how diff configuration variables are handled. You call git_config() once, and remember the values you read in set of static variables. Later, whenever you need to instantiate a grep_opt, you initialize it from these static variables. Agreed. Maybe the simplest thing would be to have grep_config fill in a static struct grep_opt grep_defaults, and then memcpy that into place during init_revisions? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Super long branch names corrupt `.git/config`
On Fri, Oct 05, 2012 at 10:36:52AM +1000, Andrew Ardill wrote: On 5 October 2012 10:29, Jeff King p...@peff.net wrote: ... but it feels a little fake. Why 200? Because that will test the config limit, but will not overflow the NAME_MAX limit (at least not on Linux! No clue on other platforms) when we try to create refs/heads/foo-$z200. I can't test this particular case right now, but I recently had an issue with Windows Server 2008 due to a long filename, that essentially meant I couldn't move, change owner or change permissions on the given file. Unless someone has more info I can test a bit later. Is the idea that we shouldn't allow filenames that will cause issues with the underlying OS (or other people's OS) or something else? I don't think it's that we shouldn't allow such filenames. It's only that the test is flaky, because making the branch name long enough to test the relaxed config code means that we may run afoul of filesystem limitations on creating the ref itself. It's a separate issue whether we should restrict the length of branch names in order to protect against filesystem limits. I tend to think not, as we handle the filesystem error just fine. The only reason to do so would be to protect people on multi-system projects (e.g., you make a long branch name on Linux that cannot be fetched to a Windows system. Or something; I did not check the limits for those systems). But I have never heard of that happening in practice, so I think we can ignore it for now. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: upload-pack is slow with lots of refs
On Thu, Oct 4, 2012 at 11:24 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 10/3/2012 21:41, schrieb Shawn Pearce: On Wed, Oct 3, 2012 at 11:55 AM, Jeff King p...@peff.net wrote: On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Has there been any work on extending the protocol so that the client tells the server what refs it's interested in? I don't think so. It would be hard to do in a backwards-compatible way, because the advertisement is the first thing the server says, before it has negotiated any capabilities with the client at all. That is being discussed but hasn't surfaced on the list. Out of curiosity, how are you thinking about triggering such a new behavior in a backwards-compatible way? Invoke git-upload-pack2, and fall back to reconnecting to start git-upload-pack if it fails? Basically, yes. New clients connect for git-upload-pack2. Over git:// the remote peer will just close the TCP socket with no messages. The client can fallback to git-upload-pack and try again. Over SSH a similar thing will happen in the sense there is no data output from the remote side, so the client can try again. These connections are bidirectional. Smart HTTP is not bidirectional. Upload-pack can just start advertising refs in the v1 way and announce a v2 capability and listen for response in parallel. A v2 capable client can start sending wants or some other signal as soon as it sees the v2 capability. Upload-pack, which was listening for responses in parallel, can interrupt its advertisements and continue with v2 protocol from here. This sounds so simple (not the implementation, of course) - I must be missing something. Smart HTTP is not bidirectional. The client can't cut off the server. Its also more complex to code the server to listen for a stop command from the client at the same time the server is blasting out useless references to the client. -- 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: Fw: [git-users] How do I git-push to an FTP server?
On Fri, 5 Oct 2012 15:46:33 +0200 Philippe Vaucher philippe.vauc...@gmail.com wrote: On the git-users mailing list we're trying someone to help with running `git push` over FTP. That person is runnig Git 1.7.9.5 on Ubuntu 12.04. I don't think vanilla git supports pushing over ftp. There are plugins like https://github.com/resmo/git-ftp tho. git-ftp's functionality is completely orthogonal to `git push` -- this script allows to sync a tree referenced by the specified Git commit with a remote directory accessible via FTP, transferring only new and modified files and deleting disappeared files and directories. IOW, git-ftp is a (very handy) Git-powered *deployment* tool, not a backend for `git push` or something like that. -- 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 04/10] attr: more matching optimizations from .gitignore
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: +Unlike `.gitignore`, negative patterns are not supported. +Patterns that match directories are also not supported. Is are not supported the right phrasing? I think it makes perfect sense not to forbid !path attr1, because it is unclear what it means (e.g. path -attr1 vs path !attr1). So I would say Negative patterns are forbidden as they do not make any sense. But for the latter, I think it makes a lot more sense to just accept path/ attr1 and doing nothing. The user requests to set an attribute to path that has to be a directory, and there is nothing wrong in such a request in itself. But nothing in git asks for attributes for directories (because we do not track directories), and such a request happens to be a no-op. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] log: pass rev_info to git_log_config()
Jeff King p...@peff.net writes: Agreed. Maybe the simplest thing would be to have grep_config fill in a static struct grep_opt grep_defaults, and then memcpy that into place during init_revisions? Yes, I was doing that for a bit last night, but then realized that the grep_config() should be split into two (grep specific part and then the bits that cascade to others, which is git grep specific requirement; it is far better to let other callers to arrange the cascading themselves) before moving the grep specific bit to the top-level, so that needs to come first. -- 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 1.8.0.rc0.18.gf84667d trouble with git commit -p file
On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand vonbr...@inf.utfsm.cl wrote: What I did: - New file images/coins.asy ~~- 'git add images/coins.asy' - Started adding new stuff to fg.tex - Noticed a old bug in fg.tex, fixed that one - Did 'git -pm Some message' and selected just the bugfix But git created a commit _including_ the new file. Tried to go back: Exactly what's supposed to happen. git add tells git you want to add the file to the index. The index is what you're going to commit later on. So what you did there was - Tell git to add images/coins.asy to the next commit - hack hack hack - fix old_bug - Add old_bug chunks of code to next commit create commit - 'git reset HEAD^' Now the new file isn't staged anymore What I expected to happen: - Only the explicitly selected chunks commited - No losing staged changes As explained above, you didn't lose staged changes, you staged more changes and committed. Then you use git reset to go back to the state of HEAD^, where the file wasn't tracked and therefore not staged either. So you're back at square one[1], commit the bug fix, then add the bugfixes in a commit and stage the new file for inclusion in your next commit. Hope this helps, Frans [1] Arguably two, since you still have changes lying around. -- 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: push.default documented in man git-push?
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano gits...@pobox.com wrote: I would recommend against listing any advice.* in the command manual pages. They are meant to give an advice in cases that are often confusing to new people and are supposed to advise how to turn it off in the message. OK. I think I was surprised that some messages were controlled by advice.* but gave no hints about that and I found that out by other means. I'll check all the advice messages. As far as I can tell, $ git grep -e 'advice\.' Documentation shows the list in config.txt and nothing else, and they do talk about when they are issued, but the reasoning behind them may not be described to a sufficient degree (that is, unless a reader carefully thinks things through, s/he may not be able to figure out why). But I think what we have there is more or less OK. It's about the commands, not the documents. For example I had no idea I could set advice.statusHints to turn off some advice. git status does not say that those messages can be turned off. OK, the messages are supposed to advise how to turn them off, so we would want some code updates in that case. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rebase: Handle cases where format-patch fails
Andrew Wong andrew.k...@gmail.com writes: 'format-patch' could fail due to reasons such as out of memory. Such failures are not detected or handled, which causes rebase to incorrectly think that it completed successfully and continue with cleanup. i.e. calling move_to_original_branch Since only the exit status of the last command in the pipeline is available, we rely on || to detect whether 'format-patch' has failed. Also print messages to help user with how to recover from such failures. Signed-off-by: Andrew Wong andrew.k...@gmail.com --- git-rebase--am.sh | 37 +++-- 1 file changed, 35 insertions(+), 2 deletions(-) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index 392ebc9..8dae804 100644 --- a/git-rebase--am.sh +++ b/git-rebase--am.sh @@ -26,10 +26,43 @@ then # makes this easy git cherry-pick --allow-empty $revisions else - git format-patch -k --stdout --full-index --ignore-if-in-upstream \ + ( git format-patch -k --stdout --full-index --ignore-if-in-upstream \ --src-prefix=a/ --dst-prefix=b/ \ - --no-renames $root_flag $revisions | + --no-renames $root_flag $revisions || + echo $? $GIT_DIR/format-patch-failed ) | Please make sure there is no marker-file that was leftover from previous invocation or whatever reason, e.g. rm -f $GIT_DIR/format-patch-failed ( git format-patch -k --stdout --full-index --ignore-if-in-upstream \ --src-prefix=a/ --dst-prefix=b/ \ --no-renames $root_flag $revisions || echo $? $GIT_DIR/format-patch-failed ) | git am $git_am_opt --rebasing --resolvemsg=$resolvemsg But when format-patch dies for whatever reason, it is likely that the partial output will cause am to barf on the last part of it (either missing patch text if it stops in the middle of commit log message, or corrupt patch if it stops in the middle of a hunk). It may make sense to make this all-or-none, i.e. when format-patch fails, you do not even start am, something like... rm -f $GIT_DIR/patch-input if ! git format-patch -k --stdout $GIT_DIR/patch-input \ --full-index --ignore-if-in-upstream \ --src-prefix=a/ --dst-prefix=b/ \ --no-renames $root_flag $revisions then ... format-patch barfed, here is how to deal with it... else git am $GIT_DIR/patch-input $git_am_opt ... fi rm -f $GIT_DIR/patch-input but I wonder what the performance implication would be for normal cases. + ret=$? + if test -f $GIT_DIR/format-patch-failed + then + ret=1 + rm -f $GIT_DIR/format-patch-failed + if test -d $state_dir + then + echo + echo 'git format-patch' seems to have failed in the middle of 'git am'. + echo If you continue rebasing, you will likely be losing some commits. + echo It is recommended that you abort rebasing by running: + echo + echo git rebase --abort + echo + else + echo + echo 'git format-patch' seems to have failed before 'git am' started. + echo It is impossible to continue or abort rebasing. + echo You have to use the following to return to your original head: + echo + case $head_name in + refs/*) + echo git checkout $head_name + ;; + *) + echo git checkout $orig_head + ;; + esac + echo + fi + fi + test 0 != $ret false fi move_to_original_branch ret=$? -- 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 pull takes ~8 seconds on up-to-date Linux git tree
Junio C Hamano gits...@pobox.com writes:
Here is a tested (in the sense that it passes the test suite, and
also in the sense that an empty pull in the kernel history gives
quick turnaround) patch. As I do not think we would want to revert
5802f81 (fmt-merge-msg: discard needless merge parents, 2012-04-18)
which was a correctness fix, I think we would rather want to do
something like this.
OK, I think I am convinced myself that this patch is the right fix.
The performance regression Markus saw is in fmt-merge-message, and
it is caused by the updated remove_redundant() that is used by
get_merge_bases_many() and reduce_heads(). On the topic branch, all
callers of reduce_heads() were passing commits that are already
parsed, but before the topic was merged to 'master', we added one
more caller to reduce_heads() on the 'master' front that passed an
unparsed commit, which is why the problem surfaced at that merge.
It might make sense to assert or die in commit_list_insert_by_date()
when a caller mistakenly pass an unparsed commit object to prevent
this kind of breakages in the future.
-- 8 --
Subject: paint_down_to_common(): parse commit before relying on its timestamp
When refactoring the merge-base computation to reduce the pairwise
O(n*(n-1)) traversals to parallel O(n) traversals, the code forgot
that timestamp based heuristics needs each commit to have been
parsed. This caused an empty git pull to spend cycles, traversing
the history all the way down to 0 (because an unparsed commit object
has 0 timestamp, and any other commit object with positive timestamp
will be processed for its parents, all getting parsed), only to come
up with a merge message to be used.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
commit.c | 5 +
1 file changed, 5 insertions(+)
diff --git i/commit.c w/commit.c
index 0246767..213bc98 100644
--- i/commit.c
+++ w/commit.c
@@ -609,6 +609,7 @@ static struct commit *interesting(struct commit_list
*list)
return NULL;
}
+/* all input commits in one and twos[] must have been parsed! */
static struct commit_list *paint_down_to_common(struct commit *one, int n,
struct commit **twos)
{
struct commit_list *list = NULL;
@@ -617,6 +618,8 @@ static struct commit_list *paint_down_to_common(struct
commit *one, int n, struc
one-object.flags |= PARENT1;
commit_list_insert_by_date(one, list);
+ if (!n)
+ return list;
for (i = 0; i n; i++) {
twos[i]-object.flags |= PARENT2;
commit_list_insert_by_date(twos[i], list);
@@ -737,6 +740,8 @@ static int remove_redundant(struct commit **array, int
cnt)
redundant = xcalloc(cnt, 1);
filled_index = xmalloc(sizeof(*filled_index) * (cnt - 1));
+ for (i = 0; i cnt; i++)
+ parse_commit(array[i]);
for (i = 0; i cnt; i++) {
struct commit_list *common;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] show color hints based on state of the git tree
By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.)
Signed-off-by: Simon Oosthoek soosth...@nieuwland.nl
---
contrib/completion/git-prompt.sh | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c50c94a..51285d7 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -53,6 +53,12 @@
# find one, or @{upstream} otherwise. Once you have set
# GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
# setting the bash.showUpstream config variable.
+#
+# If you would like a colored hint about the current dirty state, set
+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are
+# modified, the branch name turns red, when all modifications are staged
+# the branch name turns yellow and when all changes are checked in, the
+# color changes to green. The colors are currently hardcoded in the function.
# __gitdir accepts 0 or 1 arguments (i.e., location)
# returns location of .git repo
@@ -201,11 +207,12 @@ __git_ps1_show_upstream ()
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
# when called from PS1 using command substitution
# in this mode it returns text to add to bash PS1 prompt (includes branch
name) or
-# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND
+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND (pc)
# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
# when both arguments are given, the first is prepended and the second appended
# to the state string when assigned to PS1, otherwise default start/end strings
# are used.
+# In pcmode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true
__git_ps1 ()
{
local pcmode=yes
@@ -320,8 +327,37 @@ __git_ps1 ()
local f=$w$i$s$u
if [ $pcmode = yes ]; then
- PS1=$ps1pc_start($c${b##refs/heads/}${f:+
$f}$r$p)$ps1pc_end
- elif [ $pcmode = no ]; then
+ PS1=$ps1pc_start(
+ if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
+ local c_red='\e[31m'
+ local c_green='\e[32m'
+ local c_yellow='\e[33m'
+ local c_lblue='\e[1;34m'
+ local c_purple='\e[35m'
+ local c_cyan='\e[36m'
+ local c_clear='\e[0m'
+ local branchstring=$c${b##refs/heads/}
+ local branch_color=$c_green
+ local flags_color=$c_cyan
+
+ if [ $w = * ]; then
+ branch_color=$c_red
+ elif [ -n $i ]; then
+ branch_color=$c_yellow
+ fi
+
+ # Setting PS1 directly with \[ and \] around
colors
+ # is necessary to prevent wrapping issues!
+
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
+ if [ -n $f ]; then
+ PS1=$PS1
\[$flags_color\]$f\[$c_clear\]
+ fi
+ else
+ PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+ fi
+ PS1=$PS1)$ps1pc_end
+ else
+ # NO color option unless in PROMPT_COMMAND mode
printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+
$f}$r$p
fi
fi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND
changes __git_ps1 to not just allow use in setting PS1
with __git_ps1 in a command substitution, but also allows
__git_ps1 to be used as PROMPT_COMMAND in bash.
This has advantages for using color and I think it is more
elegant
Signed-off-by: Simon Oosthoek soosth...@nieuwland.nl
---
contrib/completion/git-prompt.sh | 51 +-
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 29b1ec9..c50c94a 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -10,9 +10,14 @@
#1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
#2) Add the following line to your .bashrc/.zshrc:
#source ~/.git-prompt.sh
-#3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
-# ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
+#To customize the prompt, provide start/end arguments
+#PROMPT_COMMAND=__git_ps1 '\u@\h:\w (' ')\$ '
+#3b) Alternatively change your PS1 to call __git_ps1 as
+#command-substitution:
+#Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
+#ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#the optional argument will be used as format string
#
# The argument to __git_ps1 will be displayed only if you are currently
# in a git repository. The %s token will be the name of the current
@@ -194,11 +199,41 @@ __git_ps1_show_upstream ()
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
-# returns text to add to bash PS1 prompt (includes branch name)
+# when called from PS1 using command substitution
+# in this mode it returns text to add to bash PS1 prompt (includes branch
name) or
+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second appended
+# to the state string when assigned to PS1, otherwise default start/end strings
+# are used.
__git_ps1 ()
{
+ local pcmode=yes
+ local ps1pc_start='\u@\h:\w '
+ local ps1pc_end='\$ '
+
+ case $PROMPT_COMMAND in
+ __git_ps1*)
+ if [ $# = 2 ]; then
+ ps1pc_start=$1
+ ps1pc_end=$2
+ fi
+ case $PS1 in
+ *__git_ps1*)
+ echo '[31m__git_ps1: overwriting PS1 due to
PROMPT_COMMAND[0m'
+ ;;
+ esac
+ ;;
+ *) pcmode=no ;; #no output
+ esac
+
local g=$(__gitdir)
- if [ -n $g ]; then
+ if [ -z $g ]; then
+ if [ $pcmode = yes ]; then
+ #In PC mode PS1 always needs to be set
+ PS1=$ps1pc_start$ps1pc_end
+ fi
+ else
local r=
local b=
if [ -f $g/rebase-merge/interactive ]; then
@@ -284,6 +319,10 @@ __git_ps1 ()
fi
local f=$w$i$s$u
- printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
+ if [ $pcmode = yes ]; then
+ PS1=$ps1pc_start($c${b##refs/heads/}${f:+
$f}$r$p)$ps1pc_end
+ elif [ $pcmode = no ]; then
+ printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+
$f}$r$p
+ fi
fi
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] Integrate wildmatch to git
On Fri, Oct 5, 2012 at 1:41 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
This makes wildmatch.c part of libgit.a and builds test-wildmatch; the
dependency on libpopt in the original has been replaced with the use
of our parse-options. Global variables in test-wildmatch are marked
static to avoid sparse warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Junio C Hamano gits...@pobox.com
---
.gitignore | 1 +
Makefile | 3 ++
t/t3070-wildmatch.sh | 27
test-wildmatch.c | 88
++--
wildmatch.c | 26 +---
5 files changed, 75 insertions(+), 70 deletions(-)
create mode 100755 t/t3070-wildmatch.sh
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 88585c2..bb726c8 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -19,34 +19,38 @@
/*#define COMPARE_WITH_FNMATCH*/
-#define WILD_TEST_ITERATIONS
-#include lib/wildmatch.c
+#include cache.h
+#include parse-options.h
+#include wildmatch.h
-#include popt.h
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 1024
+#endif
+#ifdef NO_STRLCPY
+#include compat/strlcpy.c
+#define strlcpy gitstrlcpy
+#endif
#ifdef COMPARE_WITH_FNMATCH
#include fnmatch.h
-int fnmatch_errors = 0;
+static int fnmatch_errors = 0;
#endif
-int wildmatch_errors = 0;
-char number_separator = ',';
+static int wildmatch_errors = 0;
typedef char bool;
-int output_iterations = 0;
-int explode_mod = 0;
-int empties_mod = 0;
-int empty_at_start = 0;
-int empty_at_end = 0;
-
-static struct poptOption long_options[] = {
- /* longName, shortName, argInfo, argPtr, value, descrip, argDesc */
- {iterations, 'i', POPT_ARG_NONE, output_iterations, 0, 0, 0},
- {empties,'e', POPT_ARG_STRING, 0, 'e', 0, 0},
- {explode,'x', POPT_ARG_INT,explode_mod, 0, 0, 0},
- {0,0,0,0, 0, 0, 0}
+static int explode_mod = 0;
Isn't static variables like this initialized to zero by default? There
is a high chance that I might be wrong though.
--
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: Fw: [git-users] How do I git-push to an FTP server?
Thomas Ferris Nicolaisen tfn...@gmail.com writes: On Fri, Oct 5, 2012 at 3:46 PM, Philippe Vaucher philippe.vauc...@gmail.com wrote: On the git-users mailing list we're trying someone to help with running `git push` over FTP. That person is runnig Git 1.7.9.5 on Ubuntu 12.04. I don't think vanilla git supports pushing over ftp. At least according to the documentation[1], Git natively supports [...] ftp. This could need some clarification if pushing over ftp is not supported. The commit 5ce4f4e (Documentation/urls: Rewrite to accomodate transport::address, 2010-04-06) that came from http://thread.gmane.org/gmane.comp.version-control.git/145196/focus=145205 was supposed to be just a clarification of the document, but it added ftp to the list without justification. Its earlier round is this http://thread.gmane.org/gmane.comp.version-control.git/143499 and it did not mention ftp; I wonder why we missed this addition during the review process. The ftp transport might have worked for fetching in the distant past for dumb and slow commit walking fetches, but it was never supposed to work with any kind of pushes as far as I know. I wouldn't be surprised if the dumb and slow commit walking fetch no longer works with ftp. -- 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 1.8.0.rc0.18.gf84667d trouble with git commit -p file
Frans Klaver franskla...@gmail.com writes: On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand vonbr...@inf.utfsm.cl wrote: What I did: - New file images/coins.asy ~~- 'git add images/coins.asy' - Started adding new stuff to fg.tex - Noticed a old bug in fg.tex, fixed that one - Did 'git -pm Some message' and selected just the bugfix But git created a commit _including_ the new file. Tried to go back: Exactly what's supposed to happen. git add tells git you want to add the file to the index. The index is what you're going to commit later on. Assuming that the last step of what Horst did was git commit -pm, I think Git is wrong in this case. When you tell git commit what to commit, unless you give -i (aka also) option, the command makes a commit to record changes only from what you tell git commit to commit, regardless of what you earlier did to the index. And choosing what to add via the interactive interface is in the same spirit as telling what to commit to git commit, so it should behave the same. This is one of the times I wish I said No, you cannot have a pony. The change was done without thinking things through, and reviewers including me did not realize this particular downside. My accepting this misfeature (or a poorly implemented feature that has a potential to be useful) was essentially me saying: When making a commit that does not match my working tree state, I always check with diff --cached to make sure what I think I am committing matches what I am committing, so I won't use such a lazy option myself. I am not excited to think things through to see what possible pitfalls the feature may have for you; I'll let you guys hang yourself with that long rope. And we are seeing a backfire from that not bothering to think things thorough. I think the right thing to do is to fix git commit -p so that it starts from the HEAD (on a temporary index), just like how partial commits are made with git commit file1 file2. Or just forbid it when the index does not match HEAD. Cf. http://thread.gmane.org/gmane.comp.version-control.git/173033/focus=173246 -- 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 1.8.0.rc0.18.gf84667d trouble with git commit -p file
On Fri, Oct 05, 2012 at 03:29:10PM -0700, Junio C Hamano wrote: Assuming that the last step of what Horst did was git commit -pm, I think Git is wrong in this case. When you tell git commit what to commit, unless you give -i (aka also) option, the command makes a commit to record changes only from what you tell git commit to commit, regardless of what you earlier did to the index. Yeah. Defaulting to -o would match the rest of git-commit's behavior much better. This is one of the times I wish I said No, you cannot have a pony. The change was done without thinking things through, and reviewers including me did not realize this particular downside. [...] Cf. http://thread.gmane.org/gmane.comp.version-control.git/173033/focus=173246 Actually, I am not sure that thread or feature is to blame. Certainly it would have been an opportune time to notice the problem. But this issue goes back much further for git commit --interactive, which has always assumed -i rather than -o. This even predates the switch from shell to C; you can see the same behavior from 6cbf07e (git-commit: add a --interactive option, 2007-03-05). I guess you could argue that --interactive and --patch should have different defaults, but I'm not sure I agree. They should both match what git commit foo does by default. I think the right thing to do is to fix git commit -p so that it starts from the HEAD (on a temporary index), just like how partial commits are made with git commit file1 file2. Or just forbid it when the index does not match HEAD. Agreed. I am inclined to call this a bugfix, though it does worry me slightly that we would be changing a behavior that has existed for so many years. We should probably also support explicit -i -p and -o -p options, as well (the former would give people who really want the existing behavior a way to get it). And the same for --interactive. I can't say I'm excited about making all that work, though. Like you, I think it is more sane to use existing tools to inspect and tweak the index to your liking, and then commit. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-svn: keep leading slash when canonicalizing paths (fallback case)
Jonathan Nieder jrnie...@gmail.com wrote: Noticed by forcing the fallback on and running tests. Without this patch, t9101.4 fails: Bad URL passed to RA layer: Unable to open an ra_local session to \ URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\ t9101-git-svn-props/svnrepo' contains unsupported hostname at \ /home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148 With it, the git-svn tests pass again. Signed-off-by: Jonathan Nieder jrnie...@gmail.com Thanks for noticing this. Signed-off-by: Eric Wong normalper...@yhbt.net and pushed to my master at git://bogomips.org/git-svn -- 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 pull takes ~8 seconds on up-to-date Linux git tree
On Fri, Oct 05, 2012 at 01:34:02PM -0700, Junio C Hamano wrote:
OK, I think I am convinced myself that this patch is the right fix.
The performance regression Markus saw is in fmt-merge-message, and
it is caused by the updated remove_redundant() that is used by
get_merge_bases_many() and reduce_heads(). On the topic branch, all
callers of reduce_heads() were passing commits that are already
parsed, but before the topic was merged to 'master', we added one
more caller to reduce_heads() on the 'master' front that passed an
unparsed commit, which is why the problem surfaced at that merge.
Thanks for tracking it down. That makes a lot of sense with the results
we are seeing.
It might make sense to assert or die in commit_list_insert_by_date()
when a caller mistakenly pass an unparsed commit object to prevent
this kind of breakages in the future.
I wonder if it would be too much to just have commit_list_insert_by_date
call parse_commit. It is, after all, the exact moment when we need to
have the date valid (and by waiting until the last minute, we can
potentially avoid parses that would not otherwise need to happen). The
overhead in the common case should basically be the same as an assert:
checking that commit-object.parsed is true (we can always inline that
bit of parse_commit if we have to).
Of course, in this case it is not just commit_list_insert_by_date that
cares. paint_down_to_common also want commit-parents to be valid; I'm
surprised that dealing with unparsed commits did not also reveal an
error there.
In an object-oriented world, we would always get the attributes of a
commit through accessors that made sure the object was parsed. That
would be nicer, but it would also mean paying for the if (parsed)
conditional a lot more frequently.
@@ -617,6 +618,8 @@ static struct commit_list *paint_down_to_common(struct
commit *one, int n, struc
one-object.flags |= PARENT1;
commit_list_insert_by_date(one, list);
+ if (!n)
+ return list;
for (i = 0; i n; i++) {
twos[i]-object.flags |= PARENT2;
commit_list_insert_by_date(twos[i], list);
This seems like an obvious optimization, but does it really have
anything to do with the patch at hand?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] attr: more matching optimizations from .gitignore
On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: +Unlike `.gitignore`, negative patterns are not supported. +Patterns that match directories are also not supported. Is are not supported the right phrasing? I think it makes perfect sense not to forbid !path attr1, because it is unclear what it means (e.g. path -attr1 vs path !attr1). So I would say Negative patterns are forbidden as they do not make any sense. OK But for the latter, I think it makes a lot more sense to just accept path/ attr1 and doing nothing. The user requests to set an attribute to path that has to be a directory, and there is nothing wrong in such a request in itself. But nothing in git asks for attributes for directories (because we do not track directories), and such a request happens to be a no-op. Or the user might think path/ attr1 sets attr1 for all files under path/ because it does not make sense to attach attributes to a directory in git. -- 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 pull takes ~8 seconds on up-to-date Linux git tree
Jeff King p...@peff.net writes:
@@ -617,6 +618,8 @@ static struct commit_list *paint_down_to_common(struct
commit *one, int n, struc
one-object.flags |= PARENT1;
commit_list_insert_by_date(one, list);
+ if (!n)
+ return list;
for (i = 0; i n; i++) {
twos[i]-object.flags |= PARENT2;
commit_list_insert_by_date(twos[i], list);
This seems like an obvious optimization, but does it really have
anything to do with the patch at hand?
The function picks one and paints it against all others, but the
logic assumes there must be at least one other to paint against;
otherwise the traversal will not ever find a node that is painted
with both PARENT1 and PARENT2 to stop, leading us to traverse all
the way down to root.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-svn: keep leading slash when canonicalizing paths (fallback case)
Eric Wong normalper...@yhbt.net writes: Jonathan Nieder jrnie...@gmail.com wrote: Noticed by forcing the fallback on and running tests. Without this patch, t9101.4 fails: Bad URL passed to RA layer: Unable to open an ra_local session to \ URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\ t9101-git-svn-props/svnrepo' contains unsupported hostname at \ /home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148 With it, the git-svn tests pass again. Signed-off-by: Jonathan Nieder jrnie...@gmail.com Thanks for noticing this. Signed-off-by: Eric Wong normalper...@yhbt.net and pushed to my master at git://bogomips.org/git-svn Will pull before 1.8.0-rc1. 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
