* Re: [PATCH v4 03/13] parseopt: make OPT_INTEGER support hexadecimal as well
From: Junio C Hamano @ 2012-02-04 5:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8Ba2qxyT4XqeRmUv63Z3rT1-FmBkZ3tB6YMh6qrXjLP1Q@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2012/2/4 Junio C Hamano <gitster@pobox.com>:
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> - *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>> + if (!prefixcmp(arg, "0x") || !prefixcmp(arg, "0X"))
>>> + *(int *)opt->value = strtol(arg + 2, (char **)&s, 16);
>>> + else
>>> + *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>
>> Can't you just do "strtol(arg, (char **)&s, 0)" instead?
>
> I could but that means "01234" is now in base 8 and that's currently
> accepted as base 10.
Yes, but I wonder if that is a problem in practice. Who in the right mind
would give 00001000 to tell git that they want one thousand?
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Tom Grennan @ 2012-02-04 5:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jasampler, tom.grennan
In-Reply-To: <7vsjirjhp7.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:
>Tom Grennan <tmgrennan@gmail.com> writes:
>
>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
>> blob) that you had tagged?
>
>No.
>
>We _designed_ our tag objects so that they are capable of pointing at
>another tag, not the object that is pointed at that other tag. And that
>is the example usage I gave you.
>
>The statement by Shawn and Jeff, "This tag is Gitster's" is exactly that.
>It was not about asserting the authenticity of the commit. It was about
>the tag object I created.
Hmm, how about "git verify-tag [[-v] [--to]] <tag|object>"?
With "--to", all tags to the given tag (or object) are verified.
Without "--to" just the given <tag> is verified.
>> gitster$ git verify-tag --pointed v1.7.10
>> tag v1.7.10: OK
>
>Just saying "$name: OK" will *never* be acceptable. "A signature made by
>any key in my keychain is fine" is not the usual use case. At least the
>output needs to be "Good signature from X".
OK, I'll have to play with the gpg --verify-options.
--
TomG
^ permalink raw reply
* Re: [PATCH v4 03/13] parseopt: make OPT_INTEGER support hexadecimal as well
From: Nguyen Thai Ngoc Duy @ 2012-02-04 6:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobtfjh9d.fsf@alter.siamese.dyndns.org>
On Sat, Feb 4, 2012 at 12:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> 2012/2/4 Junio C Hamano <gitster@pobox.com>:
>>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>>
>>>> - *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>>> + if (!prefixcmp(arg, "0x") || !prefixcmp(arg, "0X"))
>>>> + *(int *)opt->value = strtol(arg + 2, (char **)&s, 16);
>>>> + else
>>>> + *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>>
>>> Can't you just do "strtol(arg, (char **)&s, 0)" instead?
>>
>> I could but that means "01234" is now in base 8 and that's currently
>> accepted as base 10.
>
> Yes, but I wonder if that is a problem in practice. Who in the right mind
> would give 00001000 to tell git that they want one thousand?
That could come from a script, extracting info from a source (maybe a
log file) and not stripping leading zeros. If we go this route, I
think we should have one release that rejects such numbers first. If
nobody complains, then we proceed and allow octal in the next release.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Junio C Hamano @ 2012-02-04 6:20 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, jasampler, tom.grennan
In-Reply-To: <20120204055656.GC2477@tgrennan-laptop>
Tom Grennan <tmgrennan@gmail.com> writes:
> On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:
>>Tom Grennan <tmgrennan@gmail.com> writes:
>>
>>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
>>> blob) that you had tagged?
>>
>>No.
>>
>>We _designed_ our tag objects so that they are capable of pointing at
>>another tag, not the object that is pointed at that other tag. And that
>>is the example usage I gave you.
>>
>>The statement by Shawn and Jeff, "This tag is Gitster's" is exactly that.
>>It was not about asserting the authenticity of the commit. It was about
>>the tag object I created.
>
> Hmm, how about "git verify-tag [[-v] [--to]] <tag|object>"?
> With "--to", all tags to the given tag (or object) are verified.
> Without "--to" just the given <tag> is verified.
>
>>> gitster$ git verify-tag --pointed v1.7.10
>>> tag v1.7.10: OK
>>
>>Just saying "$name: OK" will *never* be acceptable. "A signature made by
>>any key in my keychain is fine" is not the usual use case. At least the
>>output needs to be "Good signature from X".
>
> OK, I'll have to play with the gpg --verify-options.
If it wasn't clear enough from my other message, I would rather not to see
any change to --verify codepath as the first step. Don't you think that
the simplest and cleanest first step is to add --points-at to the list
mode, so that with help from "| xargs git tag -v" you can bulk-verify
without any other change?
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Jeff King @ 2012-02-04 6:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <7vipjnmt8a.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 02:45:25PM -0800, Junio C Hamano wrote:
> > Nice. I was going to suggest a wrapper like "write_sh_script" so you
> > didn't have to spell out $SHELL_PATH, but I think the auto-detection
> > makes sense (and falling back to shell makes even more sense, as that
> > covers 99% of the cases anyway).
>
> Let's not over-engineer this and stick to the simple-stupid-sufficient.
>
> Something like this?
Here it is as patches with commit messages. I don't think it's worth
doing a mechanical conversion of the whole test suite to write_script.
[1/2]: tests: add write_script helper function
[2/2]: t0300: use write_script helper
-Peff
^ permalink raw reply
* [PATCH 1/2] tests: add write_script helper function
From: Jeff King @ 2012-02-04 6:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <20120204062712.GA20076@sigill.intra.peff.net>
From: Junio C Hamano <gitster@pobox.com>
Many of the scripts in the test suite write small helper
shell scripts to disk. It's best if these shell scripts
start with "#!$SHELL_PATH" rather than "#!/bin/sh", because
/bin/sh on some platforms is too buggy to be used.
However, it can be cumbersome to expand $SHELL_PATH, because
the usual recipe for writing a script is:
cat >foo.sh <<-\EOF
#!/bin/sh
echo my arguments are "$@"
EOF
To expand $SHELL_PATH, you have to either interpolate the
here-doc (which would require quoting "\$@"), or split the
creation into two commands (interpolating the $SHELL_PATH
line, but not the rest of the script). Let's provide a
helper function that makes that less syntactically painful.
While we're at it, this helper can also take care of the
"chmod +x" that typically comes after the creation of such a
script, saving the caller a line.
Signed-off-by: Jeff King <peff@peff.net>
---
I suspect you already have this in your repo, but maybe the commit
message is useful.
t/test-lib.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index b22bee7..254849e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -400,6 +400,14 @@ test_config_global () {
git config --global "$@"
}
+write_script () {
+ {
+ echo "#!${2-"$SHELL_PATH"}" &&
+ cat
+ } >"$1" &&
+ chmod +x "$1"
+}
+
# Use test_set_prereq to tell that a particular prerequisite is available.
# The prerequisite can later be checked for in two ways:
#
--
1.7.9.rc1.28.gf4be5
^ permalink raw reply related
* [PATCH 2/2] t0300: use write_script helper
From: Jeff King @ 2012-02-04 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <20120204062712.GA20076@sigill.intra.peff.net>
t0300 creates some helper shell scripts, and marks them with
"!/bin/sh". Even though the scripts are fairly simple, they
can fail on broken shells (specifically, Solaris /bin/sh
will persist a temporary assignment to IFS in a "read"
command).
Rather than work around the problem for Solaris /bin/sh,
using write_script will make sure we point to a known-good
shell that the user has given us.
Signed-off-by: Jeff King <peff@peff.net>
---
This works fine on my Linux box, but just to sanity check that I didn't
screw anything up in the whopping 5 lines of changes, can you confirm
this fixes the issue for you, Ben?
t/t0300-credentials.sh | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
index 885af8f..0b46248 100755
--- a/t/t0300-credentials.sh
+++ b/t/t0300-credentials.sh
@@ -14,14 +14,13 @@ test_expect_success 'setup helper scripts' '
done
EOF
- cat >git-credential-useless <<-\EOF &&
+ write_script git-credential-useless <<-\EOF &&
#!/bin/sh
. ./dump
exit 0
EOF
- chmod +x git-credential-useless &&
- cat >git-credential-verbatim <<-\EOF &&
+ write_script git-credential-verbatim <<-\EOF &&
#!/bin/sh
user=$1; shift
pass=$1; shift
@@ -29,7 +28,6 @@ test_expect_success 'setup helper scripts' '
test -z "$user" || echo username=$user
test -z "$pass" || echo password=$pass
EOF
- chmod +x git-credential-verbatim &&
PATH="$PWD:$PATH"
'
--
1.7.9.rc1.28.gf4be5
^ permalink raw reply related
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Tom Grennan @ 2012-02-04 6:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jasampler
In-Reply-To: <7vhaz7jf1d.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 10:20:14PM -0800, Junio C Hamano wrote:
>Tom Grennan <tmgrennan@gmail.com> writes:
>
>> On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:
>>>Tom Grennan <tmgrennan@gmail.com> writes:
>>>
>>>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
>>>> blob) that you had tagged?
>>>
>>>No.
>>>
>>>We _designed_ our tag objects so that they are capable of pointing at
>>>another tag, not the object that is pointed at that other tag. And that
>>>is the example usage I gave you.
>>>
>>>The statement by Shawn and Jeff, "This tag is Gitster's" is exactly that.
>>>It was not about asserting the authenticity of the commit. It was about
>>>the tag object I created.
>>
>> Hmm, how about "git verify-tag [[-v] [--to]] <tag|object>"?
>> With "--to", all tags to the given tag (or object) are verified.
>> Without "--to" just the given <tag> is verified.
>>
>>>> gitster$ git verify-tag --pointed v1.7.10
>>>> tag v1.7.10: OK
>>>
>>>Just saying "$name: OK" will *never* be acceptable. "A signature made by
>>>any key in my keychain is fine" is not the usual use case. At least the
>>>output needs to be "Good signature from X".
>>
>> OK, I'll have to play with the gpg --verify-options.
>
>If it wasn't clear enough from my other message, I would rather not to see
>any change to --verify codepath as the first step. Don't you think that
>the simplest and cleanest first step is to add --points-at to the list
>mode, so that with help from "| xargs git tag -v" you can bulk-verify
>without any other change?
No, I missed that. So you're suggesting,
git tag [-n[<num>]] -l [--contains <commit>] [--points-at <object>] [<pattern>...]
If so, I'll look into it tomorrow.
thanks,
TomG
^ permalink raw reply
* Re: Git performance results on a large repository
From: Nguyen Thai Ngoc Duy @ 2012-02-04 6:53 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
On Fri, Feb 3, 2012 at 9:20 PM, Joshua Redstone <joshua.redstone@fb.com> wrote:
> I timed a few common operations with both a warm OS file cache and a cold
> cache. i.e., I did a 'echo 3 | tee /proc/sys/vm/drop_caches' and then did
> the operation in question a few times (first timing is the cold timing,
> the next few are the warm timings). The following results are on a server
> with average hard drive (I.e., not flash) and > 10GB of ram.
>
> 'git status' : 39 minutes cold, and 24 seconds warm.
>
> 'git blame': 44 minutes cold, 11 minutes warm.
>
> 'git add' (appending a few chars to the end of a file and adding it): 7
> seconds cold and 5 seconds warm.
>
> 'git commit -m "foo bar3" --no-verify --untracked-files=no --quiet
> --no-status': 41 minutes cold, 20 seconds warm. I also hacked a version
> of git to remove the three or four places where 'git commit' stats every
> file in the repo, and this dropped the times to 30 minutes cold and 8
> seconds warm.
Have you tried "git update-index --assume-unchaged"? That should
reduce mass lstat() and hopefully improve the above numbers. The
interface is not exactly easy-to-use, but if it has significant gain,
then we can try to improve UI.
On the index size issue, ideally we should make minimum writes to
index instead of rewriting 191 MB index. An improvement we could do
now is to compress it, reduce disk footprint, thus disk I/O. If you
compress the index with gzip, how big is it?
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] t0300: use write_script helper
From: Junio C Hamano @ 2012-02-04 6:58 UTC (permalink / raw)
To: Jeff King; +Cc: Ben Walton, git
In-Reply-To: <20120204063018.GB21559@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> t0300 creates some helper shell scripts, and marks them with
> "!/bin/sh". Even though the scripts are fairly simple, they
> can fail on broken shells (specifically, Solaris /bin/sh
> will persist a temporary assignment to IFS in a "read"
> command).
>
> Rather than work around the problem for Solaris /bin/sh,
> using write_script will make sure we point to a known-good
> shell that the user has given us.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This works fine on my Linux box, but just to sanity check that I didn't
> screw anything up in the whopping 5 lines of changes, can you confirm
> this fixes the issue for you, Ben?
>
> t/t0300-credentials.sh | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
> index 885af8f..0b46248 100755
> --- a/t/t0300-credentials.sh
> +++ b/t/t0300-credentials.sh
> @@ -14,14 +14,13 @@ test_expect_success 'setup helper scripts' '
> done
> EOF
>
> - cat >git-credential-useless <<-\EOF &&
> + write_script git-credential-useless <<-\EOF &&
> #!/bin/sh
An innocuous facepalm I'd be glad to remove myself ;-)
> . ./dump
> exit 0
> EOF
> - chmod +x git-credential-useless &&
>
> - cat >git-credential-verbatim <<-\EOF &&
> + write_script git-credential-verbatim <<-\EOF &&
> #!/bin/sh
But other than that, looks good.
> user=$1; shift
> pass=$1; shift
> @@ -29,7 +28,6 @@ test_expect_success 'setup helper scripts' '
> test -z "$user" || echo username=$user
> test -z "$pass" || echo password=$pass
> EOF
> - chmod +x git-credential-verbatim &&
>
> PATH="$PWD:$PATH"
> '
^ permalink raw reply
* Re: [PATCH 2/2] t0300: use write_script helper
From: Jeff King @ 2012-02-04 7:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <7vd39vjda9.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 10:58:06PM -0800, Junio C Hamano wrote:
> > diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
> > index 885af8f..0b46248 100755
> > --- a/t/t0300-credentials.sh
> > +++ b/t/t0300-credentials.sh
> > @@ -14,14 +14,13 @@ test_expect_success 'setup helper scripts' '
> > done
> > EOF
> >
> > - cat >git-credential-useless <<-\EOF &&
> > + write_script git-credential-useless <<-\EOF &&
> > #!/bin/sh
>
> An innocuous facepalm I'd be glad to remove myself ;-)
Heh, it took me a second to notice it, even after you mentioned it. And
it's even right there in the context. At least the line written by
write_script takes precedence. :)
Thanks.
-Peff
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Junio C Hamano @ 2012-02-04 7:47 UTC (permalink / raw)
To: Jeff King; +Cc: Sven Strickroth, Neal Groothuis, Feanil Patel, git
In-Reply-To: <20120203213654.GD1890@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:
> ...
>> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables
>> are set, and if the core.askpass config variable is set. If any of these
>> are set, unset them. Git should fall back to a simple password prompt.
>
> Hmm, yeah that is likely the problem. I was thinking git would fall back
> to asking on the terminal, but it does not. We probably should.
How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal
topic, which is now stalled [*1*]? I do not mean this change and the other
topic textually conflict with each other---but the philosophies of this
topic and the other one seem to conflict. Not falling back to the terminal
that is not available and failing the command outright might make more
sense.
I dunno.
[Footnote]
*1* Will the topic see any action soon? I am inclined to throw the topic
into "not even the original author is not interested" category otherwise.
^ permalink raw reply
* What's cooking in git.git (Feb 2012, #01; Fri, 3)
From: Junio C Hamano @ 2012-02-04 7:51 UTC (permalink / raw)
To: git
What's cooking in git.git (Feb 2012, #01; Fri, 3)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* nd/diffstat-gramnum (2012-02-03) 1 commit
- Use correct grammar in diffstat summary line
The commands in the "git diff" family and "git apply --stat" that count
the number of files changed and the number of lines inserted/deleted have
been updated to match the output from "diffstat". This also opens the
door to i18n this line.
Will merge to 'next'.
* jx/i18n-more-marking (2012-02-01) 2 commits
- i18n: format_tracking_info "Your branch is behind" message
- i18n: git-commit whence_s "merge/cherry-pick" message
Will merge to 'next'.
* jk/grep-binary-attribute (2012-02-02) 9 commits
- grep: pre-load userdiff drivers when threaded
- grep: load file data after checking binary-ness
- grep: respect diff attributes for binary-ness
- grep: cache userdiff_driver in grep_source
- grep: drop grep_buffer's "name" parameter
- convert git-grep to use grep_source interface
- grep: refactor the concept of "grep source" into an object
- grep: move sha1-reading mutex into low-level code
- grep: make locking flag global
Fixes a longstanding bug that there was no way to tell "git grep" that a
path may look like text but it is not, which "git diff" can do using the
attributes system. Now "git grep" honors the same "binary" (or "-diff")
attribute.
Will merge to 'next'.
* jc/parse-date-raw (2012-02-03) 2 commits
- parse_date(): '@' prefix forces git-timestamp
- parse_date(): allow ancient git-timestamp
"rebase" and "commit --amend" failed to work on commits with ancient
timestamps near year 1970.
Waiting for comments.
* jk/git-dir-lookup (2012-02-02) 1 commit
- standardize and improve lookup rules for external local repos
Will merge to 'next'.
* jk/prompt-fallback-to-tty (2012-02-03) 2 commits
- prompt: fall back to terminal if askpass fails
- prompt: clean up strbuf usage
The code to ask for password did not fall back to the terminal input when
GIT_ASKPASS is set but does not work (e.g. lack of X with GUI askpass
helper).
* jk/tests-write-script (2012-02-03) 2 commits
- t0300: use write_script helper
- tests: add write_script helper function
Will merge to 'next'.
* jn/gitweb-search-utf-8 (2012-02-03) 1 commit
- gitweb: Allow UTF-8 encoded CGI query parameters and path_info
Search box in "gitweb" did not accept non-ASCII characters correctly.
Will merge to 'next'.
* jn/rpm-spec (2012-02-03) 1 commit
- git.spec: Workaround localized messages not put in any RPM
Fix breakage in v1.7.9 Makefile; rpmbuild notices an unpackaged but
installed *.mo file and fails.
Will merge to 'next'.
--------------------------------------------------
[Graduated to "master"]
* jc/pull-signed-tag (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 4257553)
+ merge: use editor by default in interactive sessions
"git merge" in an interactive session learned to spawn the editor by
default to let the user edit the auto-generated merge message, to
encourage people to explain their merges better. Legacy scripts can
export MERGE_AUTOEDIT=no to retain the historical behaviour.
* tr/merge-edit-guidance (2012-01-31) 1 commit
(merged to 'next' on 2012-01-31 at bb678f7)
+ merge: add instructions to the commit message when editing
"git merge" adds advice text to the commit log template when running
interactively.
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* nd/commit-ignore-i-t-a (2012-01-16) 2 commits
- commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
- cache-tree: update API to take abitrary flags
May want to consider this as fixing an earlier UI mistake, and not as a
feature that devides the userbase.
--------------------------------------------------
[Cooking]
* fc/zsh-completion (2012-02-03) 3 commits
- completion: simplify __gitcomp and __gitcomp_nl implementations
- completion: use ls -1 instead of rolling a loop to do that ourselves
- completion: work around zsh option propagation bug
Fix git subcommand completion for zsh (in contrib/completion).
Will merge to 'next'.
* jc/maint-request-pull-for-tag (2012-01-31) 1 commit
(merged to 'next' on 2012-02-01 at 7649f18)
+ request-pull: explicitly ask tags/$name to be pulled
When asking for a tag to be pulled, "request-pull" shows the name of the
tag prefixed with "tags/"
* nd/find-pack-entry-recent-cache-invalidation (2012-02-01) 2 commits
(merged to 'next' on 2012-02-01 at e26aed0)
+ find_pack_entry(): do not keep packed_git pointer locally
+ sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()
* nd/pack-objects-parseopt (2012-02-01) 3 commits
- pack-objects: convert to use parse_options()
- pack-objects: remove bogus comment
- pack-objects: do not accept "--index-version=version,"
Will merge to 'next'.
"pack-objects" learned use parse-options, losing custom command line
parsing code.
* bl/gitweb-project-filter (2012-02-01) 8 commits
(merged to 'next' on 2012-02-01 at 2c96ce7)
+ gitweb: Make project search respect project_filter
+ gitweb: improve usability of projects search form
+ gitweb: place links to parent directories in page header
+ gitweb: show active project_filter in project_list page header
+ gitweb: limit links to alternate forms of project_list to active project_filter
+ gitweb: add project_filter to limit project list to a subdirectory
+ gitweb: prepare git_get_projects_list for use outside 'forks'.
+ gitweb: move hard coded .git suffix out of git_get_projects_list
"gitweb" allows intermediate entries in the directory hierarchy that leads
to a projects to be clicked, which in turn shows the list of projects
inside that directory.
* rt/completion-branch-edit-desc (2012-01-29) 1 commit
(merged to 'next' on 2012-02-01 at 0627ebf)
+ completion: --edit-description option for git-branch
Originally merged to 'next' on 2012-01-31.
Will merge to 'master'.
* jn/svn-fe (2012-02-02) 47 commits
- vcs-svn: suppress a -Wtype-limits warning
- vcs-svn: allow import of > 4GiB files
- vcs-svn: rename check_overflow arguments for clarity
(merged to 'next' on 2012-02-01 at 9288c95)
+ vcs-svn/svndiff.c: squelch false "unused" warning from gcc
+ Merge branch 'svn-fe' of git://repo.or.cz/git/jrn into jn/svn-fe
+ vcs-svn: reset first_commit_done in fast_export_init
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: do not initialize report_buffer twice
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: avoid hangs from corrupt deltas
+ vcs-svn: guard against overflow when computing preimage length
+ Merge branch 'db/delta-applier' into db/text-delta
+ vcs-svn: implement text-delta handling
+ Merge branch 'db/delta-applier' into db/text-delta
+ Merge branch 'db/delta-applier' into svn-fe
+ vcs-svn: cap number of bytes read from sliding view
+ test-svn-fe: split off "test-svn-fe -d" into a separate function
+ vcs-svn: let deltas use data from preimage
+ vcs-svn: let deltas use data from postimage
+ vcs-svn: verify that deltas consume all inline data
+ vcs-svn: implement copyfrom_data delta instruction
+ vcs-svn: read instructions from deltas
+ vcs-svn: read inline data from deltas
+ vcs-svn: read the preimage when applying deltas
+ vcs-svn: parse svndiff0 window header
+ vcs-svn: skeleton of an svn delta parser
+ vcs-svn: make buffer_read_binary API more convenient
+ vcs-svn: learn to maintain a sliding view of a file
+ Makefile: list one vcs-svn/xdiff object or header per line
+ Merge branch 'db/svn-fe-code-purge' into svn-fe
+ vcs-svn: drop obj_pool
+ vcs-svn: drop treap
+ vcs-svn: drop string_pool
+ vcs-svn: pass paths through to fast-import
+ Merge branch 'db/strbufs-for-metadata' into db/svn-fe-code-purge
+ Merge branch 'db/length-as-hash' (early part) into db/svn-fe-code-purge
+ Merge branch 'db/vcs-svn-incremental' into svn-fe
+ vcs-svn: avoid using ls command twice
+ vcs-svn: use mark from previous import for parent commit
+ vcs-svn: handle filenames with dq correctly
+ vcs-svn: quote paths correctly for ls command
+ vcs-svn: eliminate repo_tree structure
+ vcs-svn: add a comment before each commit
+ vcs-svn: save marks for imported commits
+ vcs-svn: use higher mark numbers for blobs
+ vcs-svn: set up channel to read fast-import cat-blob response
+ Merge commit 'v1.7.5' into svn-fe
Originally merged to 'next' on 2012-01-29.
"vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and support
incremental imports.
Will merge to 'next' through the tip and then to 'master' soon after.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Jeff King @ 2012-02-04 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sven Strickroth, Neal Groothuis, Feanil Patel, git
In-Reply-To: <7vwr83hwg0.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 11:47:11PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:
> > ...
> >> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables
> >> are set, and if the core.askpass config variable is set. If any of these
> >> are set, unset them. Git should fall back to a simple password prompt.
> >
> > Hmm, yeah that is likely the problem. I was thinking git would fall back
> > to asking on the terminal, but it does not. We probably should.
>
> How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal
> topic, which is now stalled [*1*]? I do not mean this change and the other
> topic textually conflict with each other---but the philosophies of this
> topic and the other one seem to conflict. Not falling back to the terminal
> that is not available and failing the command outright might make more
> sense.
I don't see a conflict in the two series. That one seems to do two
things for perl programs:
1. respect SSH_ASKPASS along with GIT_ASKPASS
2. prefer askpass over asking on the terminal
But both of those are already the case in the C code.
If you look into the original complaint mentioned in the commit
messages, though, you will see that the some GUIs will appear to hang
when the terminal is prompted (because the prompt is reading from some
location invisible to the user). So in that sense, my patches could be a
regression for those users, as outright failing is better for them.
But I would argue that the bug is not prompting on the terminal, but
rather that the terminal-prompting code does not recognize when there is
no terminal connection to the user (and AFAICT, this is a Windows
problem). Any solution that doesn't fix that is really just papering
over the problem, and hurting people[1] on sane systems.
So I'd rather see the version of getpass() in compat/mingw.c better
learn to realize when we aren't actually connected to a console.
-Peff
[1] The amount of hurt is relatively small, though. It only hurts people
who set GIT_ASKPASS but can't use it (e.g., you set it in your
.bashrc because you connect via "ssh -X", but this time you happen
to be ssh-ing from a Windows box). And you can generally fix that
outside of git (e.g., by checking $DISPLAY before setting the
variable).
So one one hand, I don't want to make a decision on behavior for
Unix users because we have to cater to Windows shortcomings. On the
other hand, while fixing the root problem is preferable, if
for whatever reason we can't reliably find out whether the user is
actually going to see and respond to the prompt on Windows, it may
be practical to just paper over the issue. On the gripping hand,
after the Sven's series, TortoiseGit users would see the hang
(instead of a failure) _only_ if their askpass command failed. Which
is also perhaps not that big a deal.
^ permalink raw reply
* Re: BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline
From: Junio C Hamano @ 2012-02-04 8:11 UTC (permalink / raw)
To: Jeff King; +Cc: Mark Jason Dominus, git
In-Reply-To: <20120202223250.GA28618@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> As far as the newlines go, I'm surprised we don't reject that. We should
> probably run check_refname_format on the proposed contents of the
> symbolic-ref.
Historically the plumbing commands were deliberately left loose on the
input side in the beginning, for the explicit purpose of allowing us to
more easily experiment, tweaking the low level data structures and file
formats. It's like being able to use a disk editor to experiment with the
filesystem. You feed good data, and you will see expected results. You
perform something other parts of the system does not yet expect, and you
find places that need further adjusting if you were to extend the format
you are futzing with the "bare metal manipulation tool" ;-)
It is not surprising at all that we haven't tightened the ones that normal
users would not use, and symbolic-ref is one of them. You needed to write
scripts that would use symbolic-ref yourself more often in the early days
of Git, but back in those days, (1) people who wrote scripts with plumbing
commands tended to know what they were doing and (2) we did not have that
much interaction between subsystems, like reflogs vs symrefs.
Now, those days are long gone, and we are done with experiments pretty
much. We should tighten remaining holes as we find them.
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Junio C Hamano @ 2012-02-04 8:16 UTC (permalink / raw)
To: Jeff King; +Cc: Sven Strickroth, Neal Groothuis, Feanil Patel, git
In-Reply-To: <20120204080910.GA28317@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 03, 2012 at 11:47:11PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> ...
>> How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal
>> topic, which is now stalled [*1*]? I do not mean this change and the other
>> topic textually conflict with each other---but the philosophies of this
>> topic and the other one seem to conflict.
>
> I don't see a conflict in the two series. That one seems to do two
> things for perl programs ...
That is the "[not] textually conflict" part of my message.
> If you look into the original complaint mentioned in the commit
> messages, though, you will see that the some GUIs will appear to hang
> when the terminal is prompted (because the prompt is reading from some
> location invisible to the user). So in that sense, my patches could be a
> regression for those users, as outright failing is better for them.
Yes, that is what I meant by "philosophies conflict".
> But I would argue that the bug is not prompting on the terminal, but
> rather that the terminal-prompting code does not recognize when there is
> no terminal connection to the user (and AFAICT, this is a Windows
> problem). Any solution that doesn't fix that is really just papering
> over the problem, and hurting people[1] on sane systems.
>
> So I'd rather see the version of getpass() in compat/mingw.c better
> learn to realize when we aren't actually connected to a console.
That is a sane diagnosis, I'd have to agree.
Thanks for a dose of sanity.
> [1] The amount of hurt is relatively small, though. It only hurts people
> who set GIT_ASKPASS but can't use it (e.g., you set it in your
> .bashrc because you connect via "ssh -X", but this time you happen
> to be ssh-ing from a Windows box). And you can generally fix that
> outside of git (e.g., by checking $DISPLAY before setting the
> variable).
>
> So one one hand, I don't want to make a decision on behavior for
> Unix users because we have to cater to Windows shortcomings. On the
> other hand, while fixing the root problem is preferable, if
> for whatever reason we can't reliably find out whether the user is
> actually going to see and respond to the prompt on Windows, it may
> be practical to just paper over the issue. On the gripping hand,
> after the Sven's series, TortoiseGit users would see the hang
> (instead of a failure) _only_ if their askpass command failed. Which
> is also perhaps not that big a deal.
Wow, you do have many hands ;-).
^ permalink raw reply
* Re: Git performance results on a large repository
From: slinky @ 2012-02-04 8:57 UTC (permalink / raw)
To: git
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
Joshua Redstone <joshua.redstone <at> fb.com> writes:
> The git performance we observed here is too slow for our needs. So the
> question becomes, if we want to keep using git going forward, what's the
> best way to improve performance. It seems clear we'll probably need some
> specialized servers (e.g., to perform git-blame quickly) and maybe
> specialized file system integration to detect what files have changed in a
> working tree.
Hi Joshua,
sounds like you have everything in a single .git. Split up the massive
repository to separate smaller .git repositories.
For example, Android code base is quite big. They use the repo tool to manage a
number of separate .git repositories as one big aggregate "repository".
Cheers,
Slinky
^ permalink raw reply
* Re: Installing git-svn on Linux without root
From: Jakub Narebski @ 2012-02-04 11:32 UTC (permalink / raw)
To: Andrew Keller; +Cc: Git List
In-Reply-To: <35EF289A-1408-4B70-A25F-8194A8884A4D@kellerfarm.com>
Andrew Keller <andrew@kellerfarm.com> writes:
> I am attempting to install git, including the ability to access
> subversion repositories on a Linux machine. I do not have root
> access on the machine, so I prepended my PATH with a folder in my
> home directory.
>
> Installing Git worked just fine, but when I try to clone a
> subversion repository, I get:
>
> $ git svn clone file:///svn --prefix=svn/ --no-metadata --trunk=dba/trunk --branches=dba/branches --tags=dba/tags dba
> Initialized empty Git repository in /home/kelleran/Documents/togit/converted/dba/.git/
> Can't locate SVN/Core.pm in @INC (@INC contains: /homedirs/kelleran/local/lib/perl5/site_perl/5.8.8 /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .) at /homedirs/kelleran/local/libexec/git-core/git-svn line 41.
>
> Google suggested that the above error could be due to missing perl
> bindings. So, I installed swig, and followed the instructions for
> installing the perl bindings:
> http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL
> (I used the alternate build steps, since I had to set the prefix).
>
> Unfortunately, I still get exactly the same error. So, I looked to
> see whether or not the missing library was installed:
>
> $ find ~/local -iname Core.pm
> /homedirs/kelleran/local/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/SVN/Core.pm
>
> So, the module does exist, but not in a location included by @INC.
>From the above error message it looks like
/homedirs/kelleran/local/lib/perl5/site_perl/5.8.8
is in @INC, but
/homedirs/kelleran/local/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/
is not. Strange.
Do you use local::lib?
> This sounds like a simple misconfiguration during the installation
> on my part, but after reading the manuals and searching the web, I
> was unable to find a parameter that gets git to be able to see the
> perl bindings.
Add missing directory to PATH-like PERL5LIB environment variable
before running git-svn.
--
Jakub Narebski
^ permalink raw reply
* [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-04 12:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1328359648-29511-1-git-send-email-jnareb@gmail.com>
Introduce project_info_needs_filling($pr, $key[, @fill_only]), which
is now used in place of simple 'defined $pr->{$key}' to check if
specific slot in project needs to be filled.
This is in preparation of future lazy filling of project info in
project search and pagination of sorted list of projects. The only
functional change is that fill_project_list_info() now checks if 'age'
is already filled before running git_get_last_activity().
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This could have been squashed with the next commit, but this way it is
pure refactoring that shouldn't change gitweb behavior.
Adding project_info_needs_filling() subroutine could have been split
into separate commit, but it would be subroutine without use...
gitweb/gitweb.perl | 41 +++++++++++++++++++++++++++++++----------
1 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 913a463..b7a3752 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5185,35 +5185,56 @@ sub git_project_search_form {
print "</div>\n";
}
+# entry for given $key doesn't need filling if either $key already exists
+# in $project_info hash, or we are interested only in subset of keys
+# and given key is not among @fill_only.
+sub project_info_needs_filling {
+ my ($project_info, $key, @fill_only) = @_;
+
+ if (!@fill_only || # we are interested in everything
+ grep { $key eq $_ } @fill_only) { # or key is in @fill_only
+ # check if key is already filled
+ return !exists $project_info->{$key};
+ }
+ # uninteresting key, outside @fill_only
+ return 0;
+}
+
# fills project list info (age, description, owner, category, forks)
# for each project in the list, removing invalid projects from
-# returned list
+# returned list, or fill only specified info (removing invalid projects
+# only when filling 'age').
+#
# NOTE: modifies $projlist, but does not remove entries from it
sub fill_project_list_info {
- my $projlist = shift;
+ my ($projlist, @fill_only) = @_;
my @projects;
my $show_ctags = gitweb_check_feature('ctags');
PROJECT:
foreach my $pr (@$projlist) {
- my (@activity) = git_get_last_activity($pr->{'path'});
- unless (@activity) {
- next PROJECT;
+ if (project_info_needs_filling($pr, 'age', @fill_only)) {
+ my (@activity) = git_get_last_activity($pr->{'path'});
+ unless (@activity) {
+ next PROJECT;
+ }
+ ($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
- ($pr->{'age'}, $pr->{'age_string'}) = @activity;
- if (!defined $pr->{'descr'}) {
+ if (project_info_needs_filling($pr, 'descr', @fill_only)) {
my $descr = git_get_project_description($pr->{'path'}) || "";
$descr = to_utf8($descr);
$pr->{'descr_long'} = $descr;
$pr->{'descr'} = chop_str($descr, $projects_list_description_width, 5);
}
- if (!defined $pr->{'owner'}) {
+ if (project_info_needs_filling($pr, 'owner', @fill_only)) {
$pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
}
- if ($show_ctags) {
+ if ($show_ctags &&
+ project_info_needs_filling($pr, 'ctags', @fill_only)) {
$pr->{'ctags'} = git_get_project_ctags($pr->{'path'});
}
- if ($projects_list_group_categories && !defined $pr->{'category'}) {
+ if ($projects_list_group_categories &&
+ project_info_needs_filling($pr, 'category', @fill_only)) {
my $cat = git_get_project_category($pr->{'path'}) ||
$project_list_default_category;
$pr->{'category'} = to_utf8($cat);
--
1.7.9
^ permalink raw reply related
* [PATCH 0/5] gitweb: Faster and imrpoved project search
From: Jakub Narebski @ 2012-02-04 12:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
This patch series, though independent, is best applied on top of
"[PATCH 0/2] gitweb: Project search improvements" series, or in other
words on top of 'bl/gitweb-project-filter' branch.
First two patches in this series are about speeding up project search
(and perhaps in the future also project pagination). Those two could
be squashed together.
Next two patches are about making it more visible what are we
searching for, or rather what was matched (important especially with
regexp match). The last patch is speculative patch about showing
match using shortened description.
Jakub Narebski (5):
gitweb: Option for filling only specified info in
fill_project_list_info
gitweb: Faster project search
gitweb: Highlight matched part of project name when searching
projects
gitweb: Highlight matched part of project description when searching
projects
gitweb: Highlight matched part of shortened project description
gitweb/gitweb.perl | 122 ++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 108 insertions(+), 14 deletions(-)
--
1.7.9
^ permalink raw reply
* [PATCH/RFC 5/5] gitweb: Highlight matched part of shortened project description
From: Jakub Narebski @ 2012-02-04 12:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1328359648-29511-1-git-send-email-jnareb@gmail.com>
Previous commit make gitweb use esc_html_match_hl() to mark match in
the _whole_ description of a project when searching projects.
This commit makes gitweb highlight match in _shortened_ description,
based on match in whole description, using esc_html_match_hl_chopped()
subroutine (with some code duplication with esc_html_match_hl()).
If match is in shortened part, then trailing "... " is highlighted.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is an RFC because of code duplication between esc_html_match_hl()
and esc_html_match_hl_chopped().
gitweb/gitweb.perl | 41 ++++++++++++++++++++++++++++++++++++++++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c650268..174b4d2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1739,6 +1739,44 @@ sub esc_html_match_hl {
return $out;
}
+# highlight match (if any) of shortened string, and escape HTML
+sub esc_html_match_hl_chopped {
+ my ($str, $chopped, $regexp) = @_;
+ return esc_html($chopped) unless defined $regexp;
+ return esc_html_match_hl($str, $regexp) if ($str eq $chopped);
+
+ my @matches;
+ while ($str =~ /$regexp/g) {
+ push @matches, [$-[0], $+[0]];
+ }
+ return esc_html($chopped) unless @matches;
+
+ my $tail = "... ";
+ $chopped =~ s/\Q$tail\E$//; # see chop_str
+ my $len = length($chopped);
+ my $out = '';
+ my $pos = 0;
+ for my $m (@matches) {
+ if ($m->[0] > $len) {
+ $tail = $cgi->span({-class => 'match'}, $tail);
+ last;
+ }
+ $out .= esc_html(substr $str, $pos, $m->[0] - $pos);
+ $out .= $cgi->span({-class => 'match'},
+ esc_html(substr $chopped, $m->[0],
+ ($m->[1] > $len ? $len : $m->[1]) - $m->[0]));
+ if ($m->[1] > $len) {
+ $tail = $cgi->span({-class => 'match'}, $tail);
+ $pos = $len;
+ last;
+ }
+ $pos = $m->[1];
+ }
+ $out .= esc_html(substr($chopped, $pos)).$tail;
+
+ return $out;
+}
+
## ----------------------------------------------------------------------
## functions returning short strings
@@ -5372,7 +5410,8 @@ sub git_project_list_rows {
"<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
-class => "list", -title => $pr->{'descr_long'}},
$search_regexp
- ? esc_html_match_hl($pr->{'descr_long'}, $search_regexp)
+ ? esc_html_match_hl_chopped($pr->{'descr_long'},
+ $pr->{'descr'}, $search_regexp)
: esc_html($pr->{'descr'})) .
"</td>\n" .
"<td><i>" . chop_and_escape_str($pr->{'owner'}, 15) . "</i></td>\n";
--
1.7.9
^ permalink raw reply related
* [PATCH 4/5] gitweb: Highlight matched part of project description when searching projects
From: Jakub Narebski @ 2012-02-04 12:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1328359648-29511-1-git-send-email-jnareb@gmail.com>
Use esc_html_match_hl() from previous commit to mark match in the
_whole_ description when searching projects.
Currently, with this commit, when searching projects there is always
shown full description of a project, and not a shortened one (like for
ordinary projects list view), even if the match is on project name and
not project description.
Showing full description when there is match on it is useful to avoid
situation where match is in shortened, invisible part... well, perhaps
that could be solved (showing shortened description), but it would
require some extra code.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The part about showing match using shortened description no longer
applies after the following patch... though it is an RFC for now.
gitweb/gitweb.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index aef15c8..c650268 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5371,7 +5371,10 @@ sub git_project_list_rows {
"</td>\n" .
"<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
-class => "list", -title => $pr->{'descr_long'}},
- esc_html($pr->{'descr'})) . "</td>\n" .
+ $search_regexp
+ ? esc_html_match_hl($pr->{'descr_long'}, $search_regexp)
+ : esc_html($pr->{'descr'})) .
+ "</td>\n" .
"<td><i>" . chop_and_escape_str($pr->{'owner'}, 15) . "</i></td>\n";
print "<td class=\"". age_class($pr->{'age'}) . "\">" .
(defined $pr->{'age_string'} ? $pr->{'age_string'} : "No commits") . "</td>\n" .
--
1.7.9
^ permalink raw reply related
* [PATCH 3/5] gitweb: Highlight matched part of project name when searching projects
From: Jakub Narebski @ 2012-02-04 12:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1328359648-29511-1-git-send-email-jnareb@gmail.com>
Use newly introduced esc_html_match_hl() to escape HTML and mark match
with span element with 'match' class. Currently only 'path' part
(i.e. project name) is highlighted; match might be on the project
description.
The code makes use of the fact that defined $search_regexp means that
there was search going on.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Introducing esc_html_match_hl() could have been split into a separate
commit, but it would be subroutine without any use.
gitweb/gitweb.perl | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 95ca00f..aef15c8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1715,6 +1715,30 @@ sub chop_and_escape_str {
}
}
+# highlight match (if any), and escape HTML
+sub esc_html_match_hl {
+ my ($str, $regexp) = @_;
+ return esc_html($str) unless defined $regexp;
+
+ my @matches;
+ while ($str =~ /$regexp/g) {
+ push @matches, [$-[0], $+[0]];
+ }
+ return esc_html($str) unless @matches;
+
+ my $out = '';
+ my $pos = 0;
+ for my $m (@matches) {
+ $out .= esc_html(substr $str, $pos, $m->[0] - $pos);
+ $out .= $cgi->span({-class => 'match'},
+ esc_html(substr $str, $m->[0], $m->[1] - $m->[0]));
+ $pos = $m->[1];
+ }
+ $out .= esc_html(substr $str, $pos);
+
+ return $out;
+}
+
## ----------------------------------------------------------------------
## functions returning short strings
@@ -5342,7 +5366,9 @@ sub git_project_list_rows {
print "</td>\n";
}
print "<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
- -class => "list"}, esc_html($pr->{'path'})) . "</td>\n" .
+ -class => "list"},
+ esc_html_match_hl($pr->{'path'}, $search_regexp)) .
+ "</td>\n" .
"<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
-class => "list", -title => $pr->{'descr_long'}},
esc_html($pr->{'descr'})) . "</td>\n" .
--
1.7.9
^ permalink raw reply related
* [PATCH 2/5] gitweb: Faster project search
From: Jakub Narebski @ 2012-02-04 12:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1328359648-29511-1-git-send-email-jnareb@gmail.com>
Before searching by some field the information we search for must be
filled in. For this fill_project_list_info() was enhanced in previous
commit to take additional parameters which part of projects info to
fill. This way we can limit doing expensive calculations (like
running git-for-each-ref to get 'age' / "Last changed" info) only to
projects which we will show as search results.
With this commit the number of git commands used to generate search
results is 2*<matched projects> + 1, and depends on number of matched
projects rather than number of all projects (all repositories).
Note: this is 'git for-each-ref' to find last activity, and 'git config'
for each project, and 'git --version' once.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
search_projects_list() now pre-fills required parts of project info by
itself, so running fill_project_list_info() before calling it is no
longer necessary and actually you should not do it.
gitweb/gitweb.perl | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b7a3752..95ca00f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2989,6 +2989,10 @@ sub search_projects_list {
return @$projlist
unless ($tagfilter || $searchtext);
+ # searching projects require filling to be run before it;
+ fill_project_list_info($projlist,
+ $tagfilter ? 'ctags' : (),
+ $searchtext ? ('path', 'descr') : ());
my @projects;
PROJECT:
foreach my $pr (@$projlist) {
@@ -5370,12 +5374,13 @@ sub git_project_list_body {
# filtering out forks before filling info allows to do less work
@projects = filter_forks_from_projects_list(\@projects)
if ($check_forks);
- @projects = fill_project_list_info(\@projects);
- # searching projects require filling to be run before it
+ # search_projects_list pre-fills required info
@projects = search_projects_list(\@projects,
'searchtext' => $searchtext,
'tagfilter' => $tagfilter)
if ($tagfilter || $searchtext);
+ # fill the rest
+ @projects = fill_project_list_info(\@projects);
$order ||= $default_projects_order;
$from = 0 unless defined $from;
--
1.7.9
^ permalink raw reply related
* Re: [PATCH v4 4/4] completion: simplify __gitcomp*
From: SZEDER Gábor @ 2012-02-04 13:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, git, Jonathan Nieder, Thomas Rast,
Shawn O. Pearce
In-Reply-To: <7vty37oedr.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, Feb 03, 2012 at 12:23:12PM -0800, Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > @@ -495,11 +495,7 @@ fi
> > # 4: A suffix to be appended to each possible completion word (optional).
> > __gitcomp ()
> > {
> > - local cur_="$cur"
> > -
> > - if [ $# -gt 2 ]; then
> > - cur_="$3"
> > - fi
> > + local cur_="${3:-$cur}"
> > case "$cur_" in
> > --*=)
> > COMPREPLY=()
>
> I think this rewrite is wrong, even though it may not make a difference to
> the current callers (I didn't check). Drop the colon from ${3:-...}.
>
> > @@ -524,18 +520,8 @@ __gitcomp ()
> > # appended.
> > __gitcomp_nl ()
> > {
> > - local s=$'\n' IFS=' '$'\t'$'\n'
> > - local cur_="$cur" suffix=" "
> > -
> > - if [ $# -gt 2 ]; then
> > - cur_="$3"
> > - if [ $# -gt 3 ]; then
> > - suffix="$4"
> > - fi
> > - fi
> > -
> > - IFS=$s
> > - COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
> > + local IFS=$'\n'
> > + COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3:-$cur}"))
>
> So is this.
>
> Fixing the above two gives me what I've already sent in $gmane/189683,
> so...
>
Good point, I missed this when pointed out the similar issue with $4
earlier.
And it does make a difference, it breaks the completion of a single
word in multiple steps, e.g. git log --pretty=<TAB> master..<TAB>. In
such cases we pass "${cur##--pretty=}" and "${cur_#*..}" as third
argument to __gitcomp() and __gitcomp_nl(), which can be empty strings
when the user hits TAB right after the '=' and '..'. Replacing that
empty string with $cur is bad, because none of the possible completion
words (i.e. $1) will match it, and bash will fall back to filename
completion.
Without the colon, i.e. using "${3-$cur}", it works as expected.
Best,
Gábor
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox