* Re: [PATCH] gitweb: speed up project listing by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 0:41 UTC (permalink / raw)
To: Luke Lu; +Cc: git, gitster, Petr Baudis
In-Reply-To: <1192580691-14308-1-git-send-email-git@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> diff --git a/Makefile b/Makefile
> index 8db4dbe..b70ba8c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -165,6 +165,7 @@ GITWEB_CONFIG = gitweb_config.perl
> GITWEB_HOME_LINK_STR = projects
> GITWEB_SITENAME =
> GITWEB_PROJECTROOT = /pub/git
> +GITWEB_PROJECT_MAXDEPTH = 2
I'd rather see this default to an unlimited (or maybe insane?) depth.
Current users may be surprised upon upgrading to a more recent git
when their gitweb stops showing projects because the default depth
is too small.
repo.or.cz is up at 3 deep, maybe 4 right now, right Pasky?
I think letting admins control the depth is a good idea, but its
a performance tuning thing and probably shouldn't break existing
setups.
> + # don't traverse too deep (Find is super slow on os x)
> + return if tr!/!! - $pfxdepth > $project_maxdepth && ($File::Find::prune = 1);
I don't do much gitweb hacking, but I usually don't like to find
code that mutates a value as an important side-effect in the middle
of a boolean condition that is used to determine if we are breaking
out of this function now, or falling through to do more work. yea
its more lines of code but I think it would be easier to grok if this
was a proper if {...}.
--
Shawn.
^ permalink raw reply
* [PATCH] When renaming config sections delete conflicting sections
From: Jonas Fonseca @ 2007-10-17 0:34 UTC (permalink / raw)
To: git, Shawn O. Pearce
The old behavior of keeping config sections matching the new name caused
problems leading to warnings being emitted by git-remote when renaming
branches where information about tracked remote branches differed. To
fix this any config sections that will conflict with the new name are
removed from the config file. Update test to check for this.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
config.c | 9 ++++++++-
t/t1300-repo-config.sh | 17 +++++++++++++++++
2 files changed, 25 insertions(+), 1 deletions(-)
This command sequence was causing problems for me:
git checkout -b test madcoder/next
git checkout -b test2 spearce/next
git branch -M test
On top of spearce/next ...
diff --git a/config.c b/config.c
index dc3148d..578849a 100644
--- a/config.c
+++ b/config.c
@@ -1013,6 +1013,14 @@ int git_config_rename_section(const char *old_name, const char *new_name)
; /* do nothing */
if (buf[i] == '[') {
/* it's a section */
+ remove = 0;
+ if (new_name != NULL
+ && section_name_match (&buf[i+1], new_name)) {
+ /* Remove any existing occurences of the
+ * new section. */
+ remove = 1;
+ continue;
+ }
if (section_name_match (&buf[i+1], old_name)) {
ret++;
if (new_name == NULL) {
@@ -1026,7 +1034,6 @@ int git_config_rename_section(const char *old_name, const char *new_name)
}
continue;
}
- remove = 0;
}
if (remove)
continue;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1d2bf2c..63b969e 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -419,6 +419,23 @@ EOF
test_expect_success "section was removed properly" \
"git diff -u expect .git/config"
+cat > .git/config << EOF
+[branch "new-name"]
+ x = 1
+[branch "old-name"]
+ y = 1
+EOF
+
+test_expect_success "rename and remove old section" \
+ 'git config --rename-section branch.old-name branch.new-name'
+
+cat > expect << EOF
+[branch "new-name"]
+ y = 1
+EOF
+
+test_expect_success "rename and remove succeeded" "git diff expect .git/config"
+
rm .git/config
cat > expect << EOF
--
1.5.3.4.1206.g5f96-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] gitweb: Provide title attributes for abbreviated author names.
From: David Symonds @ 2007-10-17 0:34 UTC (permalink / raw)
To: pasky; +Cc: git, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
gitweb/gitweb.perl | 34 +++++++++++++++++++++++++++++-----
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b2bae1b..3112fd4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3461,9 +3461,15 @@ sub git_shortlog_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 10);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
# git_summary() used print "<td><i>$co{'age_string'}</i></td>\n" .
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
print format_subject_html($co{'title'}, $co{'title_short'},
href(action=>"commit", hash=>$commit), $ref);
@@ -3511,9 +3517,15 @@ sub git_history_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ # shortlog uses chop_str($co{'author_name'}, 10)
+ my $author = chop_str($co{'author_name'}, 15, 3);
+ if ($author ne $co{'author_name'}) {
+ "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- # shortlog uses chop_str($co{'author_name'}, 10)
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
# originally git_history used chop_str($co{'title'}, 50)
print format_subject_html($co{'title'}, $co{'title_short'},
@@ -3667,8 +3679,14 @@ sub git_search_grep_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}), -class => "list subject"},
esc_html(chop_str($co{'title'}, 50)) . "<br/>");
@@ -5181,8 +5199,14 @@ sub git_search {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}),
-class => "list subject"},
--
1.5.3.1
^ permalink raw reply related
* Re: Git User's Survey 2007 summary - git homepage improvements
From: david @ 2007-10-17 0:36 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jan Hudec, Frank Lichtenheld, Jakub Narebski, git,
Jonas Fonseca
In-Reply-To: <20071017002648.GH13801@spearce.org>
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
>>> On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
>>>> On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
>>>>> Generic:
>>>>> # Dedicated domain name / site name, e.g. git.org or git.com
> ...
>>>> (And I guess something like git-scm.org wouldn't qualify as more
>>>> "official", would it?)
>>>
> ...
>> If someone trustworthy in the community has the resources to sponsor the
>> domain, I will only be happy and gladly set it up on my side (I can run
>> the nameservers myself too, if required). But I don't have the
>> resources for registering the domain myself, unfortunately.
>
> "git" is a three letter word. I don't think there have been *any*
> three letter .com/.org/.net domains available for years.
>
> I see that Jonas Fonseca registered git-scm.org today... I wonder
> what his plans are for that domain...
I've been useing the .hm domain for several years. some people who don't
know what it means read it as 'home'. I see that git.hm is not allocated.
David Lang
^ permalink raw reply
* [PATCH] gitweb: speed up project listing by limiting find depth
From: Luke Lu @ 2007-10-17 0:24 UTC (permalink / raw)
To: git; +Cc: gitster, Luke Lu
Resubmit patch to make project max depth configurable.
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 8 ++++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8db4dbe..b70ba8c 100644
--- a/Makefile
+++ b/Makefile
@@ -165,6 +165,7 @@ GITWEB_CONFIG = gitweb_config.perl
GITWEB_HOME_LINK_STR = projects
GITWEB_SITENAME =
GITWEB_PROJECTROOT = /pub/git
+GITWEB_PROJECT_MAXDEPTH = 2
GITWEB_EXPORT_OK =
GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
@@ -831,6 +832,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
-e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
-e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
+ -e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
-e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
-e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
-e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3064298..1453101 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -35,6 +35,10 @@ our $GIT = "++GIT_BINDIR++/git";
#our $projectroot = "/pub/scm";
our $projectroot = "++GITWEB_PROJECTROOT++";
+# fs traversing limit for getting project list
+# the number is relative to the projectroot
+our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
+
# target of the home link on top of all pages
our $home_link = $my_uri || "/";
@@ -1509,16 +1513,20 @@ sub git_get_projects_list {
# remove the trailing "/"
$dir =~ s!/+$!!;
my $pfxlen = length("$dir");
+ my $pfxdepth = ($dir =~ tr!/!!);
File::Find::find({
follow_fast => 1, # follow symbolic links
follow_skip => 2, # ignore duplicates
+ no_chdir => 1, # don't chdir into every directory
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
return if (m!^[/.]$!);
# only directories can be git repositories
return unless (-d $_);
+ # don't traverse too deep (Find is super slow on os x)
+ return if tr!/!! - $pfxdepth > $project_maxdepth && ($File::Find::prune = 1);
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Shawn O. Pearce @ 2007-10-17 0:26 UTC (permalink / raw)
To: Petr Baudis
Cc: Jan Hudec, Frank Lichtenheld, Jakub Narebski, git, Jonas Fonseca
In-Reply-To: <20071017000526.GG18279@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> > On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > > Generic:
> > > > # Dedicated domain name / site name, e.g. git.org or git.com
...
> > > (And I guess something like git-scm.org wouldn't qualify as more
> > > "official", would it?)
> >
...
> If someone trustworthy in the community has the resources to sponsor the
> domain, I will only be happy and gladly set it up on my side (I can run
> the nameservers myself too, if required). But I don't have the
> resources for registering the domain myself, unfortunately.
"git" is a three letter word. I don't think there have been *any*
three letter .com/.org/.net domains available for years.
I see that Jonas Fonseca registered git-scm.org today... I wonder
what his plans are for that domain...
--
Shawn.
^ permalink raw reply
* Re: What's in git/spearce.git (stable)
From: Shawn O. Pearce @ 2007-10-17 0:09 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200710162228.12680.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
> On Tuesday 16 October 2007, Shawn O. Pearce wrote:
> > * The 'maint' branch has these fixes since the last announcement.
>
> There are typos in RelNotes-1.5.3.5.txt:
>
> s/wilh/will
> s/Documention/Documentation
Gah. That'll teach me to not spellcheck a documentation file before
pushing it. :-)
Thanks for catching it.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Petr Baudis @ 2007-10-17 0:05 UTC (permalink / raw)
To: Jan Hudec; +Cc: Frank Lichtenheld, Jakub Narebski, git
In-Reply-To: <20071016201247.GH26127@efreet.light.src>
On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > Generic:
> > > # Dedicated domain name / site name, e.g. git.org or git.com
> > > to have it look less like mirror or unofficial page
> > >
> > > (git.or.cz still comes first when searching Google for "git";
> > > current domain name was available to homepage admin - historical
> > > reason)
> >
> > Hmm, I guess most names that would qualify are already taken
> > (most of them by squatters, though). So someone
> > would have to pay money for this...
> > (And I guess something like git-scm.org wouldn't qualify as more
> > "official", would it?)
>
> It certainly would. It would be 2nd level domain, not a 3rd level one.
>
> Note, that none of the other vcs' have a homepage at theirname.org --
> subversion is svn.tigris.org, bazaar is bazaaz-vcs.org, mercurial is
> www.selenic.com/mercurial, svk is svk.bestpractical.com, monotone is
> monotone.ca. So git-vcs.org would be quite good.
If someone trustworthy in the community has the resources to sponsor the
domain, I will only be happy and gladly set it up on my side (I can run
the nameservers myself too, if required). But I don't have the
resources for registering the domain myself, unfortunately.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-16 23:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710161559150.6887@woody.linux-foundation.org>
On Tue, 16 Oct 2007 16:05:34 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> I do indeed. I don't think it's sensible. And I did think I already
> answered that issue by talking about how most editors don't even
> support it or show the difference between tabs and spaces.
>
> For example, the editor I use - microemacs - supports tabs just fine.
> It does auto-indentation etc. But it does it with hard-tabs by
> default, so now you have to have some editor-specific setup for that
> particular project if you ever want to do anything else.
>
> And that's really what it boils down to. Everybody support
> 8-character hardtabs (and usually by default). They may support other
> things *too*, but any time you move away from that standard
> behaviour, you'll most likely find something that doesn't support the
> alternatives.
Unfortunately most editors are totally confused about the difference
between tab size and indentation level. Visual Studio, probably the
most commonly used development environment on Windows, by default uses
TAB characters that are 4 spaces wide, and users are recommended
not to change that because of that a lot of existing Windows source code
and examples uses those settings.
Two years ago, when I last looked at it, Eclipse, a very commonly used
development environment, managed to confuse tabs and indentation and
make it almost impossible to write Java or C code with a tab size of 8
with a different indentation level. The Eclipse 3 betas did see some
improvement there, I think it got possible to do the right thing in
Java at least, but the normal text editor and C editor lagged behind.
But it was still a big mess and it was much too easy for someone to get
a tab size which is not 8. Hopefully this has been fixed by now, but I
wouldn't bet any significant amount of money on it.
Nedit (which runs on Linux) has a very confusing settings dialog with
terms such as "tab spacing", "emulated tabs". I guess emulated tabs
means the indentation level, but guess how easy that is to mess up.
gedit can control the tab width, but has no setting at all for
configuring the indentation level. Guess what people do when they want
a 4 space indentation level? Yes, right, change the tab size to 4.
A a former colleague who used visual slickedit usually produced code
with tab size 4. I think I've gotten the same crap from ultra edit 32
users.
And so on... Mercifully, _all_ of these editors have a setting to use
spaces instead of tabs, and telling people to turn on that setting is
the absolutely easiest way of making things "just work". Yes, I know,
the correct answer is to tell people to always use tab size 8, and I
frequently and loudly do that. But at the same time, perfect is the
enemy of good. It's much easier to explain "tabs will act differently
in different editors, but if you always us spaces it will not be a
problem" than to get into a discussion about the semantic difference
between tab size and indentation.
If you assume that everyone is sane and use a tab size of 8 you will
get bitten, sooner or later. Or actually, you, Linus, who are lucky
enough to work mostly with Linux source, you might personally not get
bitten all that often. But us poor suckers that have to work with
other people, often Windows programmers, we do.
/Christer
^ permalink raw reply
* Re: [PATCH] Help people in finding the download links
From: Petr Baudis @ 2007-10-17 0:01 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20071016235828.380f70a3@paolo-desktop>
On Tue, Oct 16, 2007 at 11:58:28PM +0200, Paolo Ciarrocchi wrote:
> I believe that with the following change it's a bit easier to visualize the table including the links to the tar.bz2 and tar.gz source packages.
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Thanks, applied.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: Alternative git logo and favicon
From: Petr Baudis @ 2007-10-16 23:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20071016234642.GD18279@machine.or.cz>
On Wed, Oct 17, 2007 at 01:46:42AM +0200, Petr Baudis wrote:
> Before anyone asks, I'm not against changing the logo on Git Homepage,
Darn, never mind this mail. It's all Dscho's fault because he confused
me on IRC! ;-) I didn't notice the date of this thread.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Alternative git logo and favicon
From: Petr Baudis @ 2007-10-16 23:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f62h37$1jn$1@sea.gmane.org>
On Fri, Jun 29, 2007 at 10:49:41AM +0200, Jakub Narebski wrote:
> [Cc: git@vger.kernel.org]
>
> Henrik Nyh wrote:
>
> > I came up with an alternative logo/favicon to use with my gitweb:
> > http://henrik.nyh.se/2007/06/alternative-git-logo-and-favicon.
> >
> > Thought I'd sent it to the list in case someone else likes them.
>
> Added to http://git.or.cz/gitwiki/GitRelatedLogos
>
> But for me logo is too big and wrong proportions for gitweb (although quite
> nice for git pages, I guess), and as favicon it is a bit unreadable.
Before anyone asks, I'm not against changing the logo on Git Homepage,
but before that there should be a clear consensus in the community that
$logo is better than what we currently have. Also, I think we should
strive for consistency here. I think it might be actually good to have
different logo for Git itself and another for Gitweb, but they should be
graphically similar.
I quite like Henrik's logo, but I have to admit that I got rather used
to the old one. ;-) Also, one major problem I have with it is that it
has too little contrast, the colors used seem too light to me and my eye
can't find any "support" inside the logo. This is even much worse with
the favicon where the logo isn't clearly visible on the white background
at all.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Shawn O. Pearce @ 2007-10-16 23:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710161209480.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> first let me thank you for being the interim maintainer. I know it is
> much work, and I frankly do not have the time, or nerve, to do it.
Heh. In the past 24 hours I've really learned how much I appreciate
the work that Junio does, and how infrequently I make it known that
I'm happy he's doing it for us. Nothing like understanding what
the guy goes through then to walk a day in his shoes. :-)
> Out of
> curiousity: did you use the scripts in "todo" to send these emails?
Yes. Took me a few minutes to figure out which scripts did
what magic. Junio likes two character script names, because uh,
they are short to type. Then I hand modified the output to say
git/spearce.git and appear from me, not Junio. But otherwise they
are the same scripts available from his Meta repository (aka the
todo branch).
> On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
>
> > * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
>
> AFAIR this was ready to go to master, with a 5-10% speedup or so, just
> needing a bit of testing. Which it should have gotten by now.
OK. I'll look at it tomorrow and consider moving it. I recall the
context of this discussion now that you mention it, and I've been
running this in production use since Junio committed it to next
so I'm certainly not seeing any downsides to having this patch in
the tree.
> > * kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
> > * js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
Thanks for the summary on these two topics. They are going to stay
parked in next for a while then. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] GIT home page. Mentioning that Cogito is no longer maintained.
From: Petr Baudis @ 2007-10-16 23:38 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20071016195425.016cacbe@paolo-desktop>
On Tue, Oct 16, 2007 at 07:54:25PM +0200, Paolo Ciarrocchi wrote:
> As discussed on the git mailing list
>
> http://marc.info/?l=git&m=119252168629733&w=2
>
> it seems to be a good idea to mention on the git home page that cogito
> is no longer maintained.
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Thanks. In the end, I've chosen a different formulation that should be
shorter and convey the same.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* [PATCH] Fix setup_git_directory_gently() with relative GIT_DIR & GIT_WORK_TREE
From: Johannes Schindelin @ 2007-10-16 23:37 UTC (permalink / raw)
To: git, spearce, gitster
There are a few programs, such as config and diff, which allow running
without a git repository. Therefore, they have to call
setup_git_directory_gently().
However, when GIT_DIR and GIT_WORK_TREE were set, and the current
directory was a subdirectory of the work tree,
setup_git_directory_gently() would return a bogus NULL prefix.
This patch fixes that.
Noticed by REPLeffect on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
setup.c | 13 ++++++++++++-
t/t1501-worktree.sh | 9 +++++++++
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 06004f1..145eca5 100644
--- a/setup.c
+++ b/setup.c
@@ -227,9 +227,20 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (PATH_MAX - 40 < strlen(gitdirenv))
die("'$%s' too big", GIT_DIR_ENVIRONMENT);
if (is_git_directory(gitdirenv)) {
+ static char buffer[1024 + 1];
+ const char *retval;
+
if (!work_tree_env)
return set_work_tree(gitdirenv);
- return NULL;
+ retval = get_relative_cwd(buffer, sizeof(buffer) - 1,
+ get_git_work_tree());
+ if (!retval || !*retval)
+ return NULL;
+ set_git_dir(make_absolute_path(gitdirenv));
+ if (chdir(work_tree_env) < 0)
+ die ("Could not chdir to %s", work_tree_env);
+ strcat(buffer, "/");
+ return retval;
}
if (nongit_ok) {
*nongit_ok = 1;
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 7322161..7ee3820 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -103,4 +103,13 @@ test_expect_success 'repo finds its work tree from work tree, too' '
test sub/dir/tracked = "$(git ls-files)")
'
+test_expect_success '_gently() groks relative GIT_DIR & GIT_WORK_TREE' '
+ cd repo.git/work/sub/dir &&
+ GIT_DIR=../../.. GIT_WORK_TREE=../.. GIT_PAGER= \
+ git diff --exit-code tracked &&
+ echo changed > tracked &&
+ ! GIT_DIR=../../.. GIT_WORK_TREE=../.. GIT_PAGER= \
+ git diff --exit-code tracked
+'
+
test_done
--
1.5.3.4.1223.ga973c
^ permalink raw reply related
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Michael Witten @ 2007-10-16 23:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710162348260.25221@racer.site>
On 16 Oct 2007, at 6:49:17 PM, Johannes Schindelin wrote:
>> I think fixing the tabs is more important than removing --binary.
>>
>> It's clear the the entropy of tabulation increases over time;
>> the tab patch acts as a buffer to reconstruct a clean signal.
>
> Git. The most advanced TCM - Tab Code Manager. It's not about
> source,
> it's about tabs.
>
> ;-)
I don't know whether to laugh or be miffed.
I think I'll choose to laugh. ;-D
^ permalink raw reply
* Re: [PATCH] gitweb: Speed up get_projects_list for large source trees
From: Petr Baudis @ 2007-10-16 23:20 UTC (permalink / raw)
To: Luke Lu; +Cc: git
In-Reply-To: <3A2DCEC6-953A-41B0-AB9E-7374EEB625E8@vicaya.com>
Hi,
On Tue, Oct 16, 2007 at 02:04:14AM -0700, Luke Lu wrote:
> Hi, I've been using git for a month now and loving it. This is my first
> ever patch for git using git. I spent sometime to find out why the project
> listing is taking 200s, everytime! I guess that gitweb is mostly used to
> serve bare repositories, which would never encounter such problems. It
> takes .2s, after the patch on my laptop. That's 1000x improvement for me
> (on Mac OS X 1.4.10.)
that'd be sweet to have but this is unfortunately not so simple; this
change would e.g. break gitweb on repo.or.cz, where some projects can
live quite deep inside the tree due to forks.
I guess the best way would be to introduce a configuration option that
lets you potentially limit the $pfxdepth, but does not force the limit.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: On Tabs and Spaces
From: Petr Baudis @ 2007-10-16 23:09 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Andreas Ericsson, Michael Witten, Shawn O. Pearce, git
In-Reply-To: <20071016174026.GA506@uranus.ravnborg.org>
On Tue, Oct 16, 2007 at 07:40:26PM +0200, Sam Ravnborg wrote:
> Tabs should be used for indent and not general alignment.
>
> Consider:
> <tab>if (some long condition that
> <tab>....&& spans two lines) {
> <tab><tab>my_private_printf("bla bla bla"
> <tab><tab>.................."more bla bla\n");
> <tab><tab>}
>
> This will look good and align "more bla bla\n" as
> intended no matter your tab setting.
> But replacing the 8 spaces with a tab will
> cause it to look bad.
I'd so much love to have this and sometimes do this even manually, but
does anyone have an idea how to make vim do this for me? I never got
around to investigate this in depth or possibly make a patch...
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-16 23:05 UTC (permalink / raw)
To: Tom Tobin; +Cc: git
In-Reply-To: <1192565900.6430.16.camel@athena>
On Tue, 16 Oct 2007, Tom Tobin wrote:
>
> But you then dismiss out of hand the option of using all spaces
I do indeed. I don't think it's sensible. And I did think I already
answered that issue by talking about how most editors don't even support
it or show the difference between tabs and spaces.
For example, the editor I use - microemacs - supports tabs just fine. It
does auto-indentation etc. But it does it with hard-tabs by default, so
now you have to have some editor-specific setup for that particular
project if you ever want to do anything else.
And that's really what it boils down to. Everybody support 8-character
hardtabs (and usually by default). They may support other things *too*,
but any time you move away from that standard behaviour, you'll most
likely find something that doesn't support the alternatives.
So yes, the answer really is: "git uses 8-character hard-tabs, live with
it".
Linus
^ permalink raw reply
* [PATCH] Speed up project listing for large working trees by limiting find depth
From: Luke Lu @ 2007-10-16 23:02 UTC (permalink / raw)
To: git; +Cc: gitster, Luke Lu
Forgot -s last time when resubmitting the patch.
Here is a simple gitweb patch to speed up project listing on checked
out repos with large trees. It was spending minutes in perl (5.8.8
macports). Reduced to a fraction of a second after the patch.
Signed-off-by: Luke Lu <git@vicaya.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3064298..a30eef9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1509,16 +1509,20 @@ sub git_get_projects_list {
# remove the trailing "/"
$dir =~ s!/+$!!;
my $pfxlen = length("$dir");
+ my $pfxdepth = ($dir =~ tr!/!!);
File::Find::find({
follow_fast => 1, # follow symbolic links
follow_skip => 2, # ignore duplicates
+ no_chdir => 1, # don't chdir into every directory
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
return if (m!^[/.]$!);
# only directories can be git repositories
return unless (-d $_);
+ # don't traverse too deep (Find is super slow on os x)
+ return if tr!/!! - $pfxdepth > 2 && ($File::Find::prune = 1);
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Johannes Schindelin @ 2007-10-16 22:49 UTC (permalink / raw)
To: Michael Witten; +Cc: Robin Rosenberg, git
In-Reply-To: <561D7B44-9EDE-447B-A751-BE6E3A3AD9CC@mit.edu>
Hi,
On Tue, 16 Oct 2007, Michael Witten wrote:
> On 16 Oct 2007, at 5:20:14 PM, Robin Rosenberg wrote:
>
> > So all this series does is... making it harder to follow the history?
>
> If you follow the history solely on patches.
>
>
> > Ack for removing the --binary, the rest is just noise
>
> I think fixing the tabs is more important than removing --binary.
>
> It's clear the the entropy of tabulation increases over time;
> the tab patch acts as a buffer to reconstruct a clean signal.
Git. The most advanced TCM - Tab Code Manager. It's not about source,
it's about tabs.
;-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Speed up project listing for large working trees by limiting find depth
From: Luke Lu @ 2007-10-16 22:37 UTC (permalink / raw)
To: git; +Cc: gitster, Luke Lu
Simple gitweb patch to speed up project listing on checked out repos
with large trees. It was spending minutes in perl (5.8.8 macports).
It's taking a fraction of a second after the patch. Resubmitted per
Andreas Ericsson's advice.
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3064298..a30eef9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1509,16 +1509,20 @@ sub git_get_projects_list {
# remove the trailing "/"
$dir =~ s!/+$!!;
my $pfxlen = length("$dir");
+ my $pfxdepth = ($dir =~ tr!/!!);
File::Find::find({
follow_fast => 1, # follow symbolic links
follow_skip => 2, # ignore duplicates
+ no_chdir => 1, # don't chdir into every directory
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
return if (m!^[/.]$!);
# only directories can be git repositories
return unless (-d $_);
+ # don't traverse too deep (Find is super slow on os x)
+ return if tr!/!! - $pfxdepth > 2 && ($File::Find::prune = 1);
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* [PATCH] helpful error message when send-pack finds no refs in common.
From: Andrew Clausen @ 2007-10-16 21:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 333 bytes --]
Hi all,
Please cc me, I'm not subscribed.
git-push fails when pushing into an empty repository if you don't specify
a branch:
git --bare init some-repo
git-push some-repo
To get this to work, you need to do
git-push some-repo master
I attached a patch so that the error message suggests trying the latter.
Cheers,
Andrew
[-- Attachment #2: 0001-helpful-error-message-when-send-pack-finds-no-refs-i.patch --]
[-- Type: text/plain, Size: 820 bytes --]
>From ee888ea1a7d2e75a0439569e36eabe4620e8f833 Mon Sep 17 00:00:00 2001
Date: Tue, 16 Oct 2007 17:16:05 -0400
Subject: [PATCH] helpful error message when send-pack finds no refs in common.
Signed-off-by: Andrew Clausen <clausen@econ.upenn.edu>
---
send-pack.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index f74e66a..f0b0825 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -204,7 +204,8 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
return -1;
if (!remote_refs) {
- fprintf(stderr, "No refs in common and none specified; doing nothing.\n");
+ fprintf(stderr,
+ "No refs in common and none specified; doing nothing.\n" "Perhaps you should specify a branch such as 'master'.\n");
return 0;
}
--
1.5.3.1
^ permalink raw reply related
* [PATCH] gitk: disable colours when calling git log
From: Sam Vilain @ 2007-10-16 22:33 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Sam Vilain
If the user specifies 'diff.color = 1' in their configuration file,
then gitk will not start. Disable colours when calling git log.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..999e3c2 100755
--- a/gitk
+++ b/gitk
@@ -92,7 +92,7 @@ proc start_rev_list {view} {
set order "--date-order"
}
if {[catch {
- set fd [open [concat | git log -z --pretty=raw $order --parents \
+ set fd [open [concat | git log --no-color -z --pretty=raw $order --parents \
--boundary $viewargs($view) "--" $viewfiles($view)] r]
} err]} {
error_popup "Error executing git rev-list: $err"
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* Re: git-cherry-pick no longer detecting moved files in 1.5.3.4
From: Michele Ballabio @ 2007-10-16 22:35 UTC (permalink / raw)
To: git; +Cc: Richard Quirk
In-Reply-To: <cac9e4380710161517m64ba737dj8711a6ce59b1b69@mail.gmail.com>
On Wednesday 17 October 2007, Richard Quirk wrote:
> I tried setting diff.renamelimit to -1 but to no
> avail.
It should be
diff.renamelimit = 0
to set the "unlimited" limit.
^ 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