* [PATCH 2/2] Remove NO_ACCURATE_DIFF options from build systems
From: Eric Wong @ 2006-12-23 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11668546833727-git-send-email-normalperson@yhbt.net>
The code no longer uses it, as we have --inaccurate-eof in
git-apply.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Makefile | 6 ------
configure.ac | 3 ---
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index 5492836..ebc1a17 100644
--- a/Makefile
+++ b/Makefile
@@ -79,9 +79,6 @@ all:
#
# Define NO_ICONV if your libc does not properly support iconv.
#
-# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
-# a missing newline at the end of the file.
-#
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
@@ -549,9 +546,6 @@ else
endif
endif
endif
-ifdef NO_ACCURATE_DIFF
- BASIC_CFLAGS += -DNO_ACCURATE_DIFF
-endif
ifdef NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
endif
diff --git a/configure.ac b/configure.ac
index e153d53..7cfb3a0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -235,9 +235,6 @@ AC_SUBST(NO_SETENV)
#
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
-#
-# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
-# a missing newline at the end of the file.
## Site configuration (override autodetection)
## --with-PACKAGE[=ARG] and --without-PACKAGE
--
1.4.4.3.gc902c
^ permalink raw reply related
* [PATCH 1/2] Makefile: add quick-install-doc for installing pre-built manpages
From: Eric Wong @ 2006-12-23 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
This adds and uses the install-doc-quick.sh file to
Documentation/, which is usable for people who track either the
'html' or 'man' heads in Junio's repository.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/Makefile | 3 +++
Documentation/install-doc-quick.sh | 32 ++++++++++++++++++++++++++++++++
Makefile | 2 ++
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d68bc4a..d563142 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -112,3 +112,6 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
install-webdoc : html
sh ./install-webdoc.sh $(WEBDOC_DEST)
+
+quick-install:
+ DESTDIR=$(mandir) sh ./install-doc-quick.sh man
diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh
new file mode 100644
index 0000000..44ccf60
--- /dev/null
+++ b/Documentation/install-doc-quick.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+# This requires a branch named in $head
+# (usually 'man' or 'html', provided by the git.git repository)
+set -e
+head="$1"
+if ! git-rev-parse --verify "$head" >/dev/null; then
+ echo >&2 "head: $head does not exist in the current repository"
+ exit 1
+fi
+
+if test -z "$DESTDIR"; then
+ echo >&2 'DESTDIR must be set in the environment'
+ exit 1
+fi
+
+GIT_INDEX_FILE=`pwd`/.quick-doc.index
+export GIT_INDEX_FILE
+rm -f "$GIT_INDEX_FILE"
+SUBDIRECTORY_OK=t
+. git-sh-setup
+export GIT_DIR
+git-read-tree $head
+git-checkout-index -a -f --prefix="$DESTDIR"/
+
+if test -n "$GZ"; then
+ cd "$DESTDIR"
+ for i in `git-ls-tree -r --name-only $head`
+ do
+ gzip < $i > $i.gz && rm $i
+ done
+fi
+rm -f "$GIT_INDEX_FILE"
diff --git a/Makefile b/Makefile
index 7651104..5492836 100644
--- a/Makefile
+++ b/Makefile
@@ -830,6 +830,8 @@ install: all
install-doc:
$(MAKE) -C Documentation install
+quick-install-doc:
+ $(MAKE) -C Documentation quick-install
--
1.4.4.3.gc902c
^ permalink raw reply related
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2006-12-23 6:15 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, git
In-Reply-To: <20061223051210.GA29814@segfault.peff.net>
Jeff King <peff@peff.net> writes:
> BTW, is there some explanation why branch.*.merge specifies a _remote_
> head? The following would make much more sense to me:
>
> [branch "master"]
> remote = origin
> merge = refs/remotes/origin/master
Only *if* you store it in that tracking branch. The name the
other party gives _do_ matter to you anyway, because you have to
_know_ it to fetch. What it does NOT matter is if you use a
tracking branch, or if you do, which local tracking branch you
use to track it.
^ permalink raw reply
* [PATCH] git-svn: enable common fetch/commit options for dcommit
From: Eric Wong @ 2006-12-23 5:59 UTC (permalink / raw)
To: Nicolas Vilz; +Cc: Junio C Hamano, git
In-Reply-To: <20061222122836.GD9595@hermes>
dcommit does commits and fetches, so all options used for those
should work, too, including --authors-file.
Reported missing by Nicolas Vilz.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 07748bc..4288a05 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -111,7 +111,7 @@ my %cmd = (
{ 'merge|m|M' => \$_merge,
'strategy|s=s' => \$_strategy,
'dry-run|n' => \$_dry_run,
- %cmt_opts } ],
+ %cmt_opts, %fc_opts } ],
'set-tree' => [ \&commit, "Set an SVN repository to a git tree-ish",
{ 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ],
'show-ignore' => [ \&show_ignore, "Show svn:ignore listings",
--
1.4.4.3.gc902c
^ permalink raw reply related
* Re: confusion over the new branch and merge config
From: Nicolas Pitre @ 2006-12-23 5:29 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20061223051210.GA29814@segfault.peff.net>
On Sat, 23 Dec 2006, Jeff King wrote:
> BTW, is there some explanation why branch.*.merge specifies a _remote_
> head? The following would make much more sense to me:
>
> [branch "master"]
> remote = origin
> merge = refs/remotes/origin/master
>
> Because I don't _care_ that the other guy calls it refs/heads/master. I
> care that I'm pulling from refs/remotes/origin/master on my end (and
> however I get stuff into that branch is defined by the remote).
Exactly the point I'm trying to make !
I'm glad I'm not alone to come to this conclusion.
Nicolas
^ permalink raw reply
* Re: author/commit counts
From: Shawn Pearce @ 2006-12-23 5:29 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Junio C Hamano, git
In-Reply-To: <20061222212449.dd5bf939.rdunlap@xenotime.net>
Randy Dunlap <rdunlap@xenotime.net> wrote:
> Yes, thanks, probably something like that....
>
> git version 1.4.3.GIT
>
> > git shortlog -n -s v2.6.19..
> Can't open v2.6.19..: No such file or directory at /usr/local/bin/git-shortlog line 99.
The git-shortlog being discussed is the new builtin shortlog,
which has not been released yet. Try the 'master' branch in git.git.
--
Shawn.
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Nicolas Pitre @ 2006-12-23 5:27 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Peter Baumann, git
In-Reply-To: <878xgziog0.wl%cworth@cworth.org>
On Fri, 22 Dec 2006, Carl Worth wrote:
> On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:
> > On Thu, 21 Dec 2006, Carl Worth wrote:
> >
> > > So, I think what I really want here is a complete separation in the
> > > interface between adding a path to the index and updating content into
> > > the index.
> >
> > Strangely enough I think this separation is unnecessary and redundent.
>
> One argument I would make in favor of the separation is that the two
> operations are conceptually distinct from the user point-of-view. But
> that's really hard to nail down since all users have different points
> of view and different conceptual models,
... and if we want to break the CVS model and give people a better
chance of ever grasping the git index concept I think they should not be
different.
> (though I think the recent
> post about similar file names and accidentally adding a file meant to
> be untracked is evidence in favor of this argument).
This could be used as evidence for anything. "Oh I wanted to delete
this file but that file had a similar name and I deleted the wrong
one."
> There's a much less fuzzy, and strictly technical argument that can be
> made. Right now, we document "git add" as being useful for two
> purposes, ("adding new files" and adding "modified files...to the set
> of changes").
[...]
> The technical argument for separating the notions of "add path" and
> "update content" comes from looking at how to specify path names to
> these operations, (and recursive names in particular).
Sometimes pure _technical_ arguments don't make good _user_ interfaces.
The "git add" changes are about _usability_, not _technicality_. It is
much easier to learn about one concept which is "you add stuff to your
commit" with no other distinction to make.
> Yes, update-index still exists. But we're relegating that to
> plumbing.
But plumbing is there for you to use with your own enhancements when
they are sophisticated enough like your workflow description seem to
imply.
> > The problem lies with the git-diff interface then, not git-add.
>
> I don't think so. I'm quite convinced that the fact that "git diff"
> shows the difference from the index to the working tree is correct and
> can't really be changed.
I'm not proposing to change existing output either.
> > There is no consistency needed between git-add and git-update-index.
> > The first is for users while the second is more suited for scripting
> > your own interface.
>
> But it's not actually update-index that I want. I agree that it's a
> plumbing thing that users shouldn't use. What I want is two different
> pieces of porcelain here, each focusing one one simple task. One to
> add the path to the index, and one to update content in the index for
> a path that exists.
>
> Much better would be for "git add" and "git refresh" to each just
> stick to a single task and to do it well, (git has UNIX philosophy,
> right?). So "git add" should just add paths to the index, "git
> refresh" should just update content for existing paths in the index,
> and we don't need a lot of options for either command for users to
> have to wade through.
I'm still unconvinced this is useful distinction to make in the majority
of all cases for the majority of people.
> With those simple commands, we could have nice, separate behavior for:
>
> git add some-dir
> and:
> git refresh some-dir
>
> and if someone wants the existing "add path and update content"
> behavior of git add then it should be a simple matter of aliasing to
> the combination of "git add" followed by "git refresh".
I think that if you want that behavior it might be a better idea for you
to alias those behaviors with a combination of git-ls-files and
git-update-index.
> > But the best solution is really for git-diff to have a mode where you
> > could display a diff between the work tree and the index, _or_ the index
> > and HEAD, for each file listed in the index while giving priority to the
> > former.
>
> I don't understand what you are proposing here. What would this mode
> display? How would it decide?
This is something that you might not need after all. but for people
using git-commit -a they might benefit from a git-diff -a that would
output the equivalent of what will be committed, including newly added
files (already in the index) and modified files (not yet in the index).
It is easy to do: for each index entry, generate a diff against the
corresponding file in the work tree, but if there is no difference then
generate the diff against HEAD. Modified files will be in the first
case while added files will be in the second case.
Nicolas
^ permalink raw reply
* Re: author/commit counts
From: Randy Dunlap @ 2006-12-23 5:27 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86vek3p6s3.fsf@blue.stonehenge.com>
On 22 Dec 2006 20:37:00 -0800 Randal L. Schwartz wrote:
> >>>>> "Randy" == Randy Dunlap <rdunlap@xenotime.net> writes:
>
> Randy> example:
> Randy> git log v2.6.19.. | authorcount -m | less
>
> Randy> # this is just the ones with >= 50 Author: lines
>
> Randy> Al Viro : 213
> Randy> Linus Torvalds : 94
> Randy> Jiri Slaby : 90
> Randy> Josef Sipek : 79
> Randy> Gerrit Renker : 77
> Randy> Adrian Bunk : 67
> Randy> Andrew Morton : 59
> Randy> Tejun Heo : 52
> Randy> Mariusz Kozlowski : 52
> Randy> Paul Mundt : 51
> Randy> Ralf Baechle : 50
> Randy> ---
>
> With
>
> git-log --pretty=short v2.6.19.. | git-shortlog -n -s | head -10
>
> and no additional tools, I get:
>
> Al Viro: 213
> Linus Torvalds: 94
> Jiri Slaby: 90
> Josef Sipek: 79
> Gerrit Renker: 77
> Adrian Bunk: 67
> Andrew Morton: 59
> Tejun Heo: 52
> Mariusz Kozlowski: 52
> Paul Mundt: 51
>
> Looky there.
Yep, that's nice. Thanks.
---
~Randy
^ permalink raw reply
* Re: author/commit counts
From: Randy Dunlap @ 2006-12-23 5:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyb7usqd.fsf@assigned-by-dhcp.cox.net>
On Fri, 22 Dec 2006 20:43:54 -0800 Junio C Hamano wrote:
> Randy Dunlap <rdunlap@xenotime.net> writes:
>
> > Is this useful? or it needs fixing?
> > or you already have better solutions?
> >
> > example:
> > git log v2.6.19.. | authorcount -m | less
>
> Perhaps you are talking about this command?
>
> $ git shortlog -n -s v2.6.19..
Yes, thanks, probably something like that....
git version 1.4.3.GIT
> git shortlog -n -s v2.6.19..
Can't open v2.6.19..: No such file or directory at /usr/local/bin/git-shortlog line 99.
---
~Randy
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Jeff King @ 2006-12-23 5:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vd56cam66.fsf@assigned-by-dhcp.cox.net>
On Thu, Dec 21, 2006 at 03:01:21PM -0800, Junio C Hamano wrote:
> > $ git checkout -b local_next origin/next
>
> "git checkout -b next origin/next" should work just fine, I
> think.
>
> There was a talk about allowing "checkout -b <new> <track>" to
> add branch.<new>.merge and branch.<new>.remote if <track> can be
> proven to corresond uniquely to one remote and one branch from
> that remote; I think that would match the expectation most of
> the time but that "most" would not be 100% nor even 80%, so I
> think that should be an optional feature. In any case, there
> was a talk but there is no code yet.
BTW, is there some explanation why branch.*.merge specifies a _remote_
head? The following would make much more sense to me:
[branch "master"]
remote = origin
merge = refs/remotes/origin/master
Because I don't _care_ that the other guy calls it refs/heads/master. I
care that I'm pulling from refs/remotes/origin/master on my end (and
however I get stuff into that branch is defined by the remote).
It also means that even without a remote, the merge option makes sense
(e.g., if I do repeated merges from one local branch to another). And it
means that it's _always_ correct for "checkout -b <new> <track>" to set
branch.<new>.merge to <track>, without having to worry about finding an
appropriate remote.
-Peff
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Nicolas Pitre @ 2006-12-23 5:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsabv6tm.fsf@assigned-by-dhcp.cox.net>
On Fri, 22 Dec 2006, Junio C Hamano wrote:
> Well, "request" was very inprecise word -- I should have said
> "suggestion". But I think I agree.
>
> Seconds? Thirds?
>
> -- >8 --
> [PATCH] Do not support "partial URL shorthand" anymore.
>
> We used to support specifying the top part of remote URL in
> remotes and use that as a short-hand for the URL.
>
> $ cat .git/remotes/jgarzik
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
> $ git pull jgarzik/misc-2.6
>
> This is confusing when somebody attempts to do this:
>
> $ git pull origin/foo
>
> which is not syntactically correct (unless you have origin/foo.git
> repository) and should fail, but it resulted in a mysterious
> access to the 'foo' subdirectory of the origin repository.
>
> Which was what it was designed to do, but because this is an
> oddball "feature" I suspect nobody uses, let's remove it.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Well since I suggested it I seconds this of course.
If it ever becomes useful for, say, submodules as someone pointed out,
then this can be restored at that point and done properly for the task.
Nicolas
^ permalink raw reply
* Re: author/commit counts
From: Nicolas Pitre @ 2006-12-23 5:06 UTC (permalink / raw)
To: Randy Dunlap; +Cc: git
In-Reply-To: <20061222181030.d733deb3.rdunlap@xenotime.net>
On Fri, 22 Dec 2006, Randy Dunlap wrote:
> Hi,
>
> Someone asked me a few days ago about their patches being merged yet
> (e.g., how to see their commits in a git tree).
See the --author=<string> option to git log.
> Someone else asked (in general) about commit or author counts.
>
> I pointed the first person to "git log" and/or gitweb.
> For the second, there are probably lots of scripts out there
> but I didn't find them. Where are they?
Try git shortlog -s. If you combine the two like:
git log --author=<blah> | git shortlog -s
then you'll have a commit count for <blah> only.
Nicolas
^ permalink raw reply
* Re: author/commit counts
From: Linus Torvalds @ 2006-12-23 4:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Randy Dunlap, git
In-Reply-To: <20061223023719.GA8734@spearce.org>
On Fri, 22 Dec 2006, Shawn Pearce wrote:
>
> Here's another variant showing the top 20 committers to git.git,
> no Perl involved:
This is what I've done a few times. For the kernel, I actually find the
"Signed-off-by:" lines to be more relevant to me (since it shows a
combination of authorship and maintainership, something that I value a lot
personally), but I've done statistics on both authors and signers-off )and
committers, but that mainly just shows who uses git to sync and who does
not), and I've never written any real scripts for it, I just end up doing
it with some one-liner shell thing using grep, cut, sort and uniq.
Linus
^ permalink raw reply
* Re: author/commit counts
From: Junio C Hamano @ 2006-12-23 4:43 UTC (permalink / raw)
To: Randy Dunlap; +Cc: git
In-Reply-To: <20061222181030.d733deb3.rdunlap@xenotime.net>
Randy Dunlap <rdunlap@xenotime.net> writes:
> Is this useful? or it needs fixing?
> or you already have better solutions?
>
> example:
> git log v2.6.19.. | authorcount -m | less
Perhaps you are talking about this command?
$ git shortlog -n -s v2.6.19..
^ permalink raw reply
* Re: author/commit counts
From: Randal L. Schwartz @ 2006-12-23 4:37 UTC (permalink / raw)
To: Randy Dunlap; +Cc: git
In-Reply-To: <20061222181030.d733deb3.rdunlap@xenotime.net>
>>>>> "Randy" == Randy Dunlap <rdunlap@xenotime.net> writes:
Randy> example:
Randy> git log v2.6.19.. | authorcount -m | less
Randy> # this is just the ones with >= 50 Author: lines
Randy> Al Viro : 213
Randy> Linus Torvalds : 94
Randy> Jiri Slaby : 90
Randy> Josef Sipek : 79
Randy> Gerrit Renker : 77
Randy> Adrian Bunk : 67
Randy> Andrew Morton : 59
Randy> Tejun Heo : 52
Randy> Mariusz Kozlowski : 52
Randy> Paul Mundt : 51
Randy> Ralf Baechle : 50
Randy> ---
With
git-log --pretty=short v2.6.19.. | git-shortlog -n -s | head -10
and no additional tools, I get:
Al Viro: 213
Linus Torvalds: 94
Jiri Slaby: 90
Josef Sipek: 79
Gerrit Renker: 77
Adrian Bunk: 67
Andrew Morton: 59
Tejun Heo: 52
Mariusz Kozlowski: 52
Paul Mundt: 51
Looky there.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Use rev-list pattern search options.
From: Robert Fitzsimons @ 2006-12-23 3:46 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
In-Reply-To: <11668449162618-git-send-email-robfitz@273k.net>
I forgot the --compose flag on these.
The patch 1 is just a rewrite to take advantage of the native search
support in rev-list, patch 2 and 3 are a slight change in functionality.
Robert
^ permalink raw reply
* [PATCH 2/3] gitweb: Require a minimum of two character for the search text.
From: Robert Fitzsimons @ 2006-12-23 3:35 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
In-Reply-To: <11668449162618-git-send-email-robfitz@273k.net>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
gitweb/gitweb.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cc6bd0c..6778b24 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -351,6 +351,9 @@ if (defined $searchtext) {
if ($searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
die_error(undef, "Invalid search parameter");
}
+ if (length($searchtext) < 2) {
+ die_error(undef, "At least two characters are required for search parameter");
+ }
$searchtext = quotemeta $searchtext;
}
--
1.4.4.3.gae7ae3
^ permalink raw reply related
* [PATCH 1/3] gitweb: Use rev-list pattern search options.
From: Robert Fitzsimons @ 2006-12-23 3:35 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
Use rev-list pattern search options instead of hand coded perl.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
gitweb/gitweb.perl | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ebbc397..cc6bd0c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4172,20 +4172,20 @@ sub git_search {
print "<table cellspacing=\"0\">\n";
my $alternate = 1;
if ($searchtype eq 'commit' or $searchtype eq 'author' or $searchtype eq 'committer') {
+ my $greptype;
+ if ($searchtype eq 'commit') {
+ $greptype = "--grep=";
+ } elsif ($searchtype eq 'author') {
+ $greptype = "--author=";
+ } elsif ($searchtype eq 'committer') {
+ $greptype = "--committer=";
+ }
$/ = "\0";
open my $fd, "-|", git_cmd(), "rev-list",
- "--header", "--parents", $hash, "--"
+ "--header", "--parents", ($greptype . $searchtext),
+ $hash, "--"
or next;
while (my $commit_text = <$fd>) {
- if (!grep m/$searchtext/i, $commit_text) {
- next;
- }
- if ($searchtype eq 'author' && !grep m/\nauthor .*$searchtext/i, $commit_text) {
- next;
- }
- if ($searchtype eq 'committer' && !grep m/\ncommitter .*$searchtext/i, $commit_text) {
- next;
- }
my @commit_lines = split "\n", $commit_text;
my %co = parse_commit(undef, \@commit_lines);
if (!%co) {
--
1.4.4.3.gae7ae3
^ permalink raw reply related
* [PATCH 3/3] gitweb: Allow search to be disabled from the config file.
From: Robert Fitzsimons @ 2006-12-23 3:35 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
In-Reply-To: <11668449271631-git-send-email-robfitz@273k.net>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
gitweb/gitweb.perl | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6778b24..e8f63aa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -128,6 +128,12 @@ our %feature = (
# => [content-encoding, suffix, program]
'default' => ['x-gzip', 'gz', 'gzip']},
+ # Enable text search, which will list the commits which match author,
+ # committer or commit text to a given string. Enabled by default.
+ 'search' => {
+ 'override' => 0,
+ 'default' => [1]},
+
# Enable the pickaxe search, which will list the commits that modified
# a given string in a file. This can be practical and quite faster
# alternative to 'blame', but still potentially CPU-intensive.
@@ -1729,6 +1735,9 @@ EOF
print " / $action";
}
print "\n";
+ }
+ my ($have_search) = gitweb_check_feature('search');
+ if ((defined $project) && ($have_search)) {
if (!defined $searchtext) {
$searchtext = "";
}
@@ -4147,6 +4156,10 @@ sub git_history {
}
sub git_search {
+ my ($have_search) = gitweb_check_feature('search');
+ if (!$have_search) {
+ die_error('403 Permission denied', "Permission denied");
+ }
if (!defined $searchtext) {
die_error(undef, "Text field empty");
}
--
1.4.4.3.gae7ae3
^ permalink raw reply related
* Re: confusion over the new branch and merge config
From: Tom Prince @ 2006-12-23 3:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vpsabv6tm.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 22, 2006 at 03:39:33PM -0800, Junio C Hamano wrote:
> [PATCH] Do not support "partial URL shorthand" anymore.
>
> We used to support specifying the top part of remote URL in
> remotes and use that as a short-hand for the URL.
>
> $ cat .git/remotes/jgarzik
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
> $ git pull jgarzik/misc-2.6
>
> This is confusing when somebody attempts to do this:
>
> $ git pull origin/foo
>
> which is not syntactically correct (unless you have origin/foo.git
> repository) and should fail, but it resulted in a mysterious
> access to the 'foo' subdirectory of the origin repository.
>
> Which was what it was designed to do, but because this is an
> oddball "feature" I suspect nobody uses, let's remove it.
Except with the forthcoming submodule support, this feature might become
more useful.
Tom
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Daniel Barkalow @ 2006-12-23 2:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, Peter Baumann, git
In-Reply-To: <7vfyb87bxg.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Dec 2006, Junio C Hamano wrote:
> Sure, what you want is "git add --no-add newfile", and I can
> understand that mode of operation if you are always going to
> commit with "git commit -a". Maybe we can have a config
> variable that makes "commit -a" and "add --no-add" the default
> for these two commands, and we do not have to change anything
> else.
I think there's value to a command to add an empty space with a given name
to the staging area. If you commit without -a, I don't see any reason to
think that you couldn't want the sequence "add-empty-space <new-file>",
"modify <old-file>", "update-index <old-file>", "commit", "update-index
<new-file>", "commit". It can be useful to make sure the file isn't going
to be forgotten, but also not get it into the next commit.
> One minor detail I wonder about is what mode bits would you give
> to that placeholder entry.
I looked into this at one point. It should probably use 000000 for the
mode, because it shouldn't read the working directory at all (you might
actually want to add the space before creating a file at all, for
instance, and then make a symlink when you provide anything, surprising
any reasonable guess at a mode). Also, this is going to show up in the
diff listing, and all-zero SHA1 with a mode is used there for "read the
working directory".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: author/commit counts
From: Shawn Pearce @ 2006-12-23 2:37 UTC (permalink / raw)
To: Randy Dunlap; +Cc: git
In-Reply-To: <20061222181030.d733deb3.rdunlap@xenotime.net>
Randy Dunlap <rdunlap@xenotime.net> wrote:
> Someone asked me a few days ago about their patches being merged yet
> (e.g., how to see their commits in a git tree).
> Someone else asked (in general) about commit or author counts.
I often do `git log --author=Shawn next@{1}..next` to see what
commits of mine Junio has recently merged into git.git since my
last fetch. Since I'm the only Shawn (with that spelling) that
contributes to git.git this works rather well to show my work. ;-)
> I pointed the first person to "git log" and/or gitweb.
> For the second, there are probably lots of scripts out there
> but I didn't find them. Where are they?
Here's another variant showing the top 20 committers to git.git,
no Perl involved:
$ git log | grep ^Author | cut -d\< -f1 | sort \
| uniq -c | sort -n -r | head -20
3728 Author: Junio C Hamano
842 Author: Linus Torvalds
250 Author: Johannes Schindelin
217 Author: Jakub Narebski
194 Author: Eric Wong
166 Author: Petr Baudis
150 Author: Paul Mackerras
147 Author: Kay Sievers
88 Author: Nicolas Pitre
77 Author: Rene Scharfe
67 Author: Shawn Pearce
57 Author: Martin Langhoff
53 Author: Fredrik Kuivinen
52 Author: Nick Hengeveld
52 Author: Matthias Urlichs
49 Author: Daniel Barkalow
47 Author: Ryan Anderson
46 Author: Shawn O. Pearce
45 Author: Sergey Vlasov
45 Author: Luben Tuikov
The only issue I have with that is I seem to have two attributions
in git.git: 'Shawn Pearce' and 'Shawn O. Pearce'. Technically I'm
in the top 10 by commit volume but its not immediately clear because
of the two attributions being used. Really my only issue here is
why sometimes my middle initial gets used and other times it doesn't.
You can also see the very clear gap between Junio and the rest of the
world. There's very little dispute about who really codes Git. :-)
I'm personally suprised at Pasky's ranking: 166 commits! I did
not realize he had contributed so frequently to git.git itself.
--
Shawn.
^ permalink raw reply
* author/commit counts
From: Randy Dunlap @ 2006-12-23 2:10 UTC (permalink / raw)
To: git
Hi,
Someone asked me a few days ago about their patches being merged yet
(e.g., how to see their commits in a git tree).
Someone else asked (in general) about commit or author counts.
I pointed the first person to "git log" and/or gitweb.
For the second, there are probably lots of scripts out there
but I didn't find them. Where are they?
Is this useful? or it needs fixing?
or you already have better solutions?
example:
git log v2.6.19.. | authorcount -m | less
# this is just the ones with >= 50 Author: lines
Al Viro : 213
Linus Torvalds : 94
Jiri Slaby : 90
Josef Sipek : 79
Gerrit Renker : 77
Adrian Bunk : 67
Andrew Morton : 59
Tejun Heo : 52
Mariusz Kozlowski : 52
Paul Mundt : 51
Ralf Baechle : 50
---
#! /usr/bin/perl
# Copyright (C) 2006, Randy Dunlap.
# read stdin, drop non-author: lines, count/sum/tally author: lines by
# each author after sanitizing author-name somewhat.
#
# optionally print out in author-name (-a) alpha order
# or in numeric/count (-n) order (low-to-high)
# or in numeric/count (-m) order (high-to-low) ("max" first)
# hash for author names:
my %authors;
my $auth;
my $sortby;
sub usage()
{
print "usage: authorcount [-a | -n | -m] < git.log.lines\n";
exit(1);
}
$sortby = $ARGV[0];
if (($sortby ne "") && ($sortby ne "-a") && ($sortby ne "-n") &&
($sortby ne "-m"))
{
print "Invalid sort option: $sortby\n";
usage();
}
READIN: while ($line = <STDIN>)
{
chomp $line;
next READIN if $line !~ /Author:/;
$auth = $line;
$auth =~ s/Author: //;
$auth =~ s/<.*>//;
$authors{$auth}++;
} # end READIN
sub byvalue
{
$authors{$a} <=> $authors{$b};
}
# optionally sort by author name or author counts
# print out the tally array
if ($sortby eq "-a")
{
foreach $auth (sort keys %authors)
{
print "$auth: $authors{$auth}\n";
}
}
elsif ($sortby eq "-n")
{
foreach $auth (sort byvalue keys %authors)
{
print "$auth: $authors{$auth}\n";
}
}
elsif ($sortby eq "-m")
{
foreach $auth (reverse sort byvalue keys %authors)
{
print "$auth: $authors{$auth}\n";
}
}
else # no sort, just hash order
{
while (($auth, $count) = each(%authors))
{
print "$auth: $count\n";
}
}
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Josef Weidendorfer @ 2006-12-23 0:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vlkkzv6rq.fsf@assigned-by-dhcp.cox.net>
On Saturday 23 December 2006 00:40, you wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > On Friday 2006 December 22 09:37, Junio C Hamano wrote:
> >
> >> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
> >> + git-add --interactive: hunk splitting
> >> + git-add --interactive
> >
> > I used this to disentangle a load of changes that I made under pressure and
> > turned them into lovely isolated commits. I didn't have any trouble with it,
> > and thought it was incredibly useful.
> >
> > I'd vote for putting it in 1.5 - it's in keeping with the usability theme -
> > people love interactive stuff.
>
> Seconds? Thirds? Vetoes?
Seconds. I like it.
Andy: Did you check whether your disentangled commits each actually did compile
on their own? If yes, how did you do it?
Josef
^ permalink raw reply
* Re: warning merge message
From: Josef Weidendorfer @ 2006-12-23 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <7vy7ozv8lz.fsf@assigned-by-dhcp.cox.net>
On Saturday 23 December 2006 00:00, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > In a previous discussion, you talked about switching to
> > the new behavior (ie. getting rid of this "first set of
> > branches" rule) when there is at least one branch.*.merge
> > setting in the config file.
> >
> > Unfortunately I can not see an easy way to check this with
> > repo-config, as there is no wildcard support for keys
> > (Ok, I can do a list of keys and grep).
>
> I think --get-regexp is what you want -- see my "patch for
> discussion".
I see. I just read the thread.
The git mailing list is already quite high volume ;-)
Around 150+ new postings a day.
I think I first should browse through any new threads before
answering any mail.
> > I think it is better to provide an option
> > "pull.do-not-follow-the-first-set-of-branches-rule".
> > And we should make this the default after init-db or clone.
>
> Yes, but the problem is that old timers do make new clones.
Yes, they do.
But this is not breaking existing repositories.
If you collect such incompatibilities for the 1.5.0 release
notes and provide the workaround ("remove that pull.do-not ..."
option) to get back the old behavior, it should be fine.
I can imagine that we want to add branch.*.remote/merge lines
with "git checkout -b XXX remotes/YYY". Of course this should
only be done if the pull.do-not is set. Relying on existance
branch.*.merge lines seems fragile for me.
What about putting this option into the config template instead of
setting it in clone?
If somebody always wants the old behavior, he should provide a template
with this option not set.
> pull.i-like-the-first-set-of-branches in ~/.gitconfig is the
> only thing I can think of but that is too ugly and is already on
> the slippery slope of user.expert configuration which I do not
> think we want.
I agree.
Josef
^ 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