* [PATCH] gitweb: speed up project listing on large work trees by limiting find depth
From: Luke Lu @ 2007-10-17 3:45 UTC (permalink / raw)
To: git; +Cc: pasky, spearce, Luke Lu
Resubmitting patch after passing gitweb regression tests.
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 10 ++++++++++
t/t9500-gitweb-standalone-no-errors.sh | 1 +
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8db4dbe..3e9938e 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 = 2007
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..48e21da 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,6 +1513,7 @@ 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
@@ -1519,6 +1524,11 @@ sub git_get_projects_list {
return if (m!^[/.]$!);
# only directories can be git repositories
return unless (-d $_);
+ # don't traverse too deep (Find is super slow on os x)
+ if (($File::Find::name =~ tr!/!!) - $pfxdepth > $project_maxdepth) {
+ $File::Find::prune = 1;
+ return;
+ }
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 642b836..f7bad5b 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -18,6 +18,7 @@ gitweb_init () {
our \$version = "current";
our \$GIT = "git";
our \$projectroot = "$(pwd)";
+our \$project_maxdepth = 8;
our \$home_link_str = "projects";
our \$site_name = "[localhost]";
our \$site_header = "";
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] gitweb: speed up project listing on large work trees by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 4:00 UTC (permalink / raw)
To: Luke Lu; +Cc: git, pasky
In-Reply-To: <1192592725-28143-1-git-send-email-git@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> Resubmitting patch after passing gitweb regression tests.
...
> @@ -1519,6 +1524,11 @@ sub git_get_projects_list {
> return if (m!^[/.]$!);
> # only directories can be git repositories
> return unless (-d $_);
> + # don't traverse too deep (Find is super slow on os x)
> + if (($File::Find::name =~ tr!/!!) - $pfxdepth > $project_maxdepth) {
> + $File::Find::prune = 1;
> + return;
> + }
Thanks. I'm squashing this into your patch. I'm not sure what
the impact is of altering $File::Find::name in the middle of the
find algorithm and I'm not sure we want to figure that out later.
We found out the hard way today that altering a non-local'd $_
in the function is what was causing the breakage.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 48e21da..9f47c3f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1525,7 +1525,8 @@ sub git_get_projects_list {
# only directories can be git repositories
return unless (-d $_);
# don't traverse too deep (Find is super slow on os x)
- if (($File::Find::name =~ tr!/!!) - $pfxdepth > $project_maxdepth) {
+ local $_ = $File::Find::name;
+ if (tr!/!! - $pfxdepth > $project_maxdepth) {
$File::Find::prune = 1;
return;
}
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] gitweb: speed up project listing on large work trees by limiting find depth
From: Luke Lu @ 2007-10-17 4:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, pasky
In-Reply-To: <20071017040028.GT13801@spearce.org>
On Oct 16, 2007, at 9:00 PM, Shawn O. Pearce wrote:
> Luke Lu <git@vicaya.com> wrote:
>> Resubmitting patch after passing gitweb regression tests.
> ...
>> @@ -1519,6 +1524,11 @@ sub git_get_projects_list {
>> return if (m!^[/.]$!);
>> # only directories can be git repositories
>> return unless (-d $_);
>> + # don't traverse too deep (Find is super slow on os x)
>> + if (($File::Find::name =~ tr!/!!) - $pfxdepth >
>> $project_maxdepth) {
>> + $File::Find::prune = 1;
>> + return;
>> + }
>
> Thanks. I'm squashing this into your patch. I'm not sure what
> the impact is of altering $File::Find::name in the middle of the
> find algorithm and I'm not sure we want to figure that out later.
> We found out the hard way today that altering a non-local'd $_
> in the function is what was causing the breakage.
This is generally a good advice. But tr!/!! doesn't alter the string
at all (OK, replicates it), unless you use the /d option. tr/stuff//
is an idiom to count stuff. Check perldoc perlop for details. I don't
think it's necessary.
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 48e21da..9f47c3f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1525,7 +1525,8 @@ sub git_get_projects_list {
> # only directories can be git repositories
> return unless (-d $_);
> # don't traverse too deep (Find is super slow on os x)
> - if (($File::Find::name =~ tr!/!!) - $pfxdepth >
> $project_maxdepth) {
> + local $_ = $File::Find::name;
> + if (tr!/!! - $pfxdepth > $project_maxdepth) {
> $File::Find::prune = 1;
> return;
> }
> --
> Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: speed up project listing on large work trees by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 4:27 UTC (permalink / raw)
To: Luke Lu; +Cc: git, pasky
In-Reply-To: <6B74E96C-37ED-4D6A-8A98-C90B61EFA181@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> On Oct 16, 2007, at 9:00 PM, Shawn O. Pearce wrote:
> >
> >Thanks. I'm squashing this into your patch. I'm not sure what
> >the impact is of altering $File::Find::name in the middle of the
> >find algorithm and I'm not sure we want to figure that out later.
> >We found out the hard way today that altering a non-local'd $_
> >in the function is what was causing the breakage.
>
> This is generally a good advice. But tr!/!! doesn't alter the string
> at all (OK, replicates it), unless you use the /d option. tr/stuff//
> is an idiom to count stuff. Check perldoc perlop for details. I don't
> think it's necessary.
Oh. Yea, I see what you mean now. So the bug was really that you
were matching on $_ not $File::Find::name. But according to perldoc
File::Find $_ and $File::Find::name are the same when no_chdir =>
1 which your patch also sets. So I'm really not seeing how the
updated version fixes the bug.
> >diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> >index 48e21da..9f47c3f 100755
> >--- a/gitweb/gitweb.perl
> >+++ b/gitweb/gitweb.perl
> >@@ -1525,7 +1525,8 @@ sub git_get_projects_list {
> > # only directories can be git repositories
> > return unless (-d $_);
> > # don't traverse too deep (Find is super
> > slow on os x)
> >- if (($File::Find::name =~ tr!/!!) -
> >$pfxdepth > $project_maxdepth) {
> >+ local $_ = $File::Find::name;
> >+ if (tr!/!! - $pfxdepth > $project_maxdepth) {
> > $File::Find::prune = 1;
> > return;
> > }
--
Shawn.
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Shawn O. Pearce @ 2007-10-17 4:44 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: René Scharfe, git, Nicolas Pitre
In-Reply-To: <20071016165045.GB13946@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> On Tue, Oct 16, 2007 at 04:38:36PM +0000, René Scharfe wrote:
> > Pierre Habouzit schrieb:
> > > This bit is to allow to aggregate options with arguments together when
> > > the argument is numeric.
> > >
> > > +#if 0
> > > + /* can be used to understand -A1B1 like -A1 -B1 */
> > > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > > + return 0;
> > > + }
> > > +#endif
> >
> > I don't like it, it complicates number options with unit suffixes (e.g.
> > --windows-memory of git-pack-objects).
...
> This is a very strong argument _against_ this chunk IMO.
Since everyone (including myself) is apparently strongly against this
hunk I removed it when I cherry-picked this series from Pierre into
my tree. The series will be in my pu tonight, but minus this hunk.
--
Shawn.
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.
From: Pete/Piet Delaney @ 2007-10-17 5:02 UTC (permalink / raw)
To: Marco Costalba
Cc: Linus Torvalds, VMiklos, free cycle, git, piet.delaney,
Piet Delaney
In-Reply-To: <e5bfff550710152156t33ba10dam6171e3210c18d3ac@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marco Costalba wrote:
Hi Marco:
I've gone back and tried my old Qgit 1.5.3 and it was
much closer in functionality to Bitkeeper.
> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> I just download 'meld', looks interesting, I didn't know about it or
>> 'kompare'. Linking either one into gitk would be a pleasant graphical
>> 'bling'.
>>
>
> In case you are interested a git GUI viewer called qgit can spawn
> 'Kompare' , 'Meld' or any other diff tool that support 'two files'
> command line interface:
>
> $my_preferred_diff_tool file1.txt file2.txt
>
> And they will show what you are looking for. The input files are
> prepared by qgit that also handles the housekeeping at the end.
While I'm looking at the diffs for a file if I pull down External Diff
it launches 'kcompare' but for a file with a large change it seems
to be running extremely slow. We have a file with 13,000 files in it
and I have two changes in the file, each is an addition and deletion
of about 100 lines in one contiguous block. If I click between them
it's fine but since the 100 lines is more than one page I try to
scroll thru the diff. At this point of time 'kompare' seems to be
using 95% of the CPU time and it takes about 10 seconds for it to
scroll. It scrolls fine in the qgit diff window. It;s not a problem
for small files. Know of what can me done so that 'kcompare' works
fast on large files; something like pointing it's tmp files to a
not NFS partition.
Another problem I've noticed is that sometime while running git
it seems to spend a large amount of time switching from one
change-set to the next; seems to be due to all of the tagged
files.
> Another feature you asked, i.e. CTRL + right click to select a
> revision (different from the parent) to diff against the current one
> is also already implemented.
It seems that while I'm in "Rev List" mode I can select the the
two versions to compare a selected file with View->External diff...
Now, if I pull down "View File" or go to the file context were
you see the change-set for a file then I can't get the CTRL + right
click to allow me to diff two revisions of the file.
While messing around in this area of trying to diff two revision
of the file from the file context I got:
- ------------------------------------------------------------------
/nethome/piet/src/blux$ qgit
Saving cache. Please wait...
Compressing data...
Done.
Saving cache. Please wait...
Compressing data...
Done.
ASSERT in getAncestor: empty file from
e86306878efb575be80d070ac3dec49f8d358cd1
ASSERT in lookupAnnotation: no annotation for cli/quagga-0.96/lib/bluelane.c
ASSERT in remove: 8 is not the first in list
Thrown exception 'Canceling annotation'
Exception 'Canceling annotation' not handled in init...re-throw
terminate called after throwing an instance of 'i'
Aborted
/nethome/piet/src/blux$
- ------------------------------------------------------------------
MY guess is that I should install a newer version of qgit,
I'm using 1.5.3.
How difficult is it to upgrade to the Qt4. Can I just
install it to /usr/local and not interfere with Qt3?
Last I recall messing with installing ethereal from src
I needed a graphics lib and as I recall installing it in
/usr/local/ confused some build crap. It would be interesting
to try out your new qgit-2.0.
>
> And of course the two above features can be integrated: you select two
> random revisions and then call the external diff viewer to check at
> the differences in the way you prefer.
Right, but how do I do this from the file context?
>
> It is possible to download qgit from
>
> http://sourceforge.net/project/showfiles.php?group_id=139897
>
>
> Two versions:
>
> qgit-1.5.7 is Qt3 based
>
> qgit-2.0 is Qt4 based (works also under Windows)
Picked up both, I'll start with qgit-1.5.7.
Installing qt4 might not be so easy; looking at:
http://packages.qa.debian.org/q/qt4-x11.html
it seems to be pretty big. The date on 1.5.7 was very
close to 2.0 so I thought they might be very close in
functionality and you maintaining the same code for
both the common Qt3 and the new Qt4 to make it easy
for users to install.
Regards,
Piet
>
>
>
> regards
> Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFZd4JICwm/rv3hoRAgMVAJ0d49Sbbuppt8o5F1U7tbkaQjSQzwCfV0nn
mnFXyUWIKGhoxz7pqulJeVk=
=Jq+Y
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Pete/Piet Delaney @ 2007-10-17 5:22 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <e5bfff550710160211g5dbfa7fai95386b173edc45c3@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marco Costalba wrote:
> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> It's not quite a intuitive/familiar as with bitkeeper. I suspect I just
>> need some practice. I selected a huge list if files that we use to
>> filter the release with and double clicked on the file I thought showing
>> to focus on that file. The I pulled down External Diff and it took for
>> ever; like it's confused.
>>
>
> You shoudl select only _one_ additional revision.
>
> The currenlty selected revision is the base + select another one
> (only) with CTRL + *RIGHT* click (the file list change background
> color) , then call external diff tool.
>
>> Often we/I want to see the rev history for a particular file.
>> How would you do that with Qgit?
>>
>
> Select the file from the file list (right bottom pane) or from the
> tree view (use key 't' to toggle treev view) double click on it or use
> context menu (right click on the file name) and that's all.
't' worked fine but still can see how to diff do of the list of
changes for a file. Viewing diffs of files based on change sets
worked fine but I think with BitKeeper I found it helpful to be
able to do a full 'kompare' type diff the file only; often I'm
not interested in which change set it went into.
Something for a future version or am I lucky and you have
it covered already?
>
>> Can I see just the revs for a particular file?
>>
>
> See above.
>
>
> I know I'm going to tell you a very _unpopular_ thing, but, in case
> you have 5 minutes of spare time (yes, it doesn't take longer), open
> qgit then please press a nice key called 'F1', a nice handbook will
> appear...
Good Idea, thought it's brought up a few questions:
1. When I do the <control-minis> to Decrease the font size
I can't undo it with the <control-plus>. Also <control-plus>
doesn't seem to do anything.
2. When displaying the "Lane info" why can't I see the
branch names?
>
> I really suggest to look at it. To keep UI 'clean' a lot of features
> are not immediatly visible, so reading the handbook (at least the
> chapter's titiles) would give you a better idea of what qgit could do
> for you.
I'll read it a few more times. I seem to sometimes get into a state
where I'm locked onto the current change set and can't get back to
the other change sets without starting another qgit.
>
>> I'll get the latest and greatest. Thinks. Often the problem is
>> having the current version of Qt3. My workstation is Mandrake
>> 1005 Limited Edition (X11 Xinerama works on this release).
>> Looks like I have Qt3 on my workstation. Would it be worthwhile
>> to install Qt4 from src and try to use qgit-2.0?
>>
>
> Yes it is. There are a lot of new featrures, is almost as stable as
> the previous and if you are interested in file history (annotations)
> in qgit-2.0 this feature has been greatly speeded up.
Do you know if it's a lot of work to install Qt4?
- -piet
>
>
> Have fun
> Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFZv5JICwm/rv3hoRAky6AJ47DFL/pWa8CCHv0ezw0wdkLLmbIQCeJqZN
cNHuMINv2/7fmnwczWcowhs=
=VSZN
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] gitweb: speed up project listing on large work trees by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 5:25 UTC (permalink / raw)
To: Luke Lu; +Cc: git, pasky
In-Reply-To: <562B5254-2BE7-43DF-AB62-499458E360CC@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> OK, let me try again :) I was using no_chdir => 1 to shorten the tr,
> as well as saving a syscall. However the code is expecting $_ to be
> relative elsewhere (line 1524) to check for the toplevel, so the
> check failed for the toplevel because of no_chdir, which caused
> substr to work on the toplevel, which is $pfxlen long. Note $pfxlen +
> 1 passes the end of the toplevel path, hence the errors, though the
> program still worked correctly, as $subdir is undefined in this case,
> which would by pass the rest of the code, which is logically correct.
> It'll probably crash, if it's written in C :)
>
> So, I got rid of no_chdir => 1 in the new patch and uses
> $File::Find::name directly, as otherwise I'd have to come up with a
> messier regex for checking toplevel at line 1524.
*light dawns*. Thank you for the explanation.
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kastrup @ 2007-10-17 5:56 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0710161559150.6887@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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.
Actually, it seriously degrades (both performance and savings)
deltifying once you reach an indentation of 16.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] rev-list documentation: add "--bisect-all".
From: Christian Couder @ 2007-10-17 6:05 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin, Frank Lichtenheld,
Ralf Wildenhues; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-rev-list.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
This is a resend with some typos fixed.
Thanks to Ralf Wildenhues.
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 7cd0e89..4852804 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -34,6 +34,7 @@ SYNOPSIS
[ \--pretty | \--header ]
[ \--bisect ]
[ \--bisect-vars ]
+ [ \--bisect-all ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
@@ -354,6 +355,21 @@ the expected number of commits to be tested if `bisect_rev`
turns out to be bad to `bisect_bad`, and the number of commits
we are bisecting right now to `bisect_all`.
+--bisect-all::
+
+This outputs all the commit objects between the included and excluded
+commits, ordered by their distance to the included and excluded
+commits. The farthest from them is displayed first. (This is the only
+one displayed by `--bisect`.)
+
+This is useful because it makes it easy to choose a good commit to
+test when you want to avoid to test some of them for some reason (they
+may not compile for example).
+
+This option can be used along with `--bisect-vars`, in this case,
+after all the sorted commit objects, there will be the same text as if
+`--bisect-vars` had been used alone.
+
--
Commit Ordering
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Jakub Narebski @ 2007-10-17 6:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20071017011835.GH18279@machine.or.cz>
On 10/17/07, Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
>> # Information about MS Windows version(s). Link to MSys Git, marking
>> it as under development; perhaps plea for help?
>
> I'm not sure what in particular the MSys people want... They may want to
> send patches, though. ;-)
>
> Maybe we could merge the (largely artificially separated anyway)
> subproject subsections to a single alphabetically-ordered subsection and
> include MSysGit there?
I was thinking more about adding link to MSysGit / GitMe / WInGit in the
"Getting Git"/"Binaries" section. I'm not sure what people who put this response
in survey want...
>> * Perhaps making some pages like FAQ or Tips and Tricks, or
>> discussion about nature of branches in git taken from GitWiki when
>> they are mature enough
>
> This touches a subject that I'm kind of surprised wasn't mentioned more,
> that is the homepage-wiki duality. Are people happy with the current
> setup? I kinda am, or would be if I got more patches. ;-) I'm personally
> not too fond of having project's main homepage in wiki -
> *especially* if it's made obvious by half of the screen space being
> occupied by wiki-generated metalinks. But if everyone else thinks that
> we should just move the main page to a wiki format, I won't stay in the
> way.
>
> I'd like to use this space to also repeat that I never seriously
> intended to maintain the technical side of the wiki, I've set up just
> because it was so damn easy. I have grown to just hate the wiki engine
> we use, and if someone wants to take the wiki over, you are welcome!
I'm very happy with homepage / wiki separation. IMVHO having wiki for
homepage is not a very good decision. I thought that wiki would be
more staging area for homepage, and that some content after maturing
would be put on homepage.
--
Jakub Narebski
^ permalink raw reply
* Re: A note from the interim Git maintainer
From: Eric Wong @ 2007-10-17 6:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Benoit Sigoure, Eygene Ryabinkin
In-Reply-To: <20071016055448.GA13801@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> As most folks are probably now well aware, Junio has been offline
> for about 11 days and may still be offline for a little while more.
> Before he dropped offline Junio shared why he left on such a short
> notice with both Dscho and myself, as it meant cancelling the
> "git together" we were planning to have last weekend in San Jose.
>
> I'm not going to get into the specific details as it is Junio's
> business and not mine. But I can say that my thoughts and prayers
> to $DEITY are with him and his family at this time, and I don't
> expect him to be rushing back to git work tomorrow. However I'm
> quite certain that Junio will return when he can.
>
> I've decided to step up and try to fill Junio's shoes. To that end
> I am publishing a maint, master, next (and soon) pu branch from a
> new fork on repo.or.cz:
Thanks for doing this, Shawn. I hope Junio is doing OK.
I've pushed out Benoit's and Eygene's latest git-svn changes to master
on http://git.bogomips.org/git-svn.git These changes are against
spearce/master.
I've amended Benoit's commit messages a bit and fixed one bug in
git svn propget (also amended).
Benoit Sigoure (5):
git-svn: add a generic tree traversal to fetch SVN properties
git-svn: implement git svn create-ignore
git-svn: add git svn propget
git-svn: add git svn proplist
git-svn: simplify the handling of fatal errors
Eygene Ryabinkin (2):
git-svn: respect Subversion's [auth] section configuration values
git-svn: use "no warnings 'once'" to disable false-positives
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/6] more compact progress display
From: Johannes Sixt @ 2007-10-17 6:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <1192586150-13743-2-git-send-email-nico@cam.org>
Nicolas Pitre schrieb:
> - start_progress_delay(&progress, "Checking %u files out...",
> - "", total, 50, 2);
> + start_progress_delay(&progress, "Checking files out",
> + total, 50, 2);
While you are here, could you make that "Checking out files", please?
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/6] more compact progress display
From: Shawn O. Pearce @ 2007-10-17 6:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, git
In-Reply-To: <4715ACE4.9080907@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Nicolas Pitre schrieb:
> >- start_progress_delay(&progress, "Checking %u files out...",
> >- "", total, 50, 2);
> >+ start_progress_delay(&progress, "Checking files out",
> >+ total, 50, 2);
>
> While you are here, could you make that "Checking out files", please?
I'll amend it right now. I'm finishing up building my nightly
update to git/spearce.git and this is about to go into next.
So... you just caught me in time to do an amend. :-)
--
Shawn.
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Marco Costalba @ 2007-10-17 6:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: pete, Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <4714EF53.8090707@op5.se>
On 10/16/07, Andreas Ericsson <ae@op5.se> wrote:
> Marco Costalba wrote:
> > On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
> >
> >> Would it be worthwhile
> >> to install Qt4 from src and try to use qgit-2.0?
> >>
> >
> > Yes it is. There are a lot of new featrures, is almost as stable as
> > the previous and if you are interested in file history (annotations)
> > in qgit-2.0 this feature has been greatly speeded up.
> >
>
> The only thing I really, really, really don't like about qgit4 is the
> fact that it fudges up the commit-message. I've been trying for two
> days to get rid of the HTML output, but I just can't get it done
> without the signed-off-by email being enclosed in <> tags.
>
You mean when you commit some changes or when you brows the revisions?
If it is the highlighted title that annoy you I can try to remove the
background color, or set as plain text as an option.
> view without the colored box a lot more). The little arrows in the
> commit window are also fairly annoying, as one quite quickly understands
> that up-/down-arrows work much better for that sort of stuff anyway.
>
Little arrows should already be removable from settings->browse->'Show
smart labels' , you can also add lateral tabs with
settings->browse->'Show tabbed revisions' if you like.
Marco
^ permalink raw reply
* Re: A note from the interim Git maintainer
From: Shawn O. Pearce @ 2007-10-17 7:13 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Junio C Hamano, Benoit Sigoure, Eygene Ryabinkin
In-Reply-To: <20071017063132.GA458@soma>
Eric Wong <normalperson@yhbt.net> wrote:
> I've pushed out Benoit's and Eygene's latest git-svn changes to master
> on http://git.bogomips.org/git-svn.git These changes are against
> spearce/master.
>
> I've amended Benoit's commit messages a bit and fixed one bug in
> git svn propget (also amended).
Thanks. I originally skipped over Benoit's changes as I hadn't see
anything from you on the subject. But I have now cherry-picked them
from your bogomips git-svn tree into spearce/master. Pushing it
out in a minute.
> Benoit Sigoure (5):
> git-svn: add a generic tree traversal to fetch SVN properties
> git-svn: implement git svn create-ignore
> git-svn: add git svn propget
> git-svn: add git svn proplist
> git-svn: simplify the handling of fatal errors
>
> Eygene Ryabinkin (2):
> git-svn: respect Subversion's [auth] section configuration values
> git-svn: use "no warnings 'once'" to disable false-positives
I apparently already had that first one from Eygene ("[auth]
section") in spearce/master; it went out last night. Perhaps you
ran the shortlog above against Junio's tree and not mine?
The second one from Eygene ("no warnings once") I already had in
my master from the resend you had earlier made to the list with
your Ack and fixups.
--
Shawn.
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Marco Costalba @ 2007-10-17 7:14 UTC (permalink / raw)
To: pete; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <47159BF9.9040400@bluelane.com>
On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
> 't' worked fine but still can see how to diff do of the list of
> changes for a file. Viewing diffs of files based on change sets
> worked fine but I think with BitKeeper I found it helpful to be
> able to do a full 'kompare' type diff the file only; often I'm
> not interested in which change set it went into.
>
Well, open tree view ('t'), select the file you are interested of,
then click the magic wand button on the tool bar, now revisions you
see are filtered by that file, if you browse the revisions the
patch/diff you see will always point to your file (also if you can see
the whole patch).
> Something for a future version or am I lucky and you have
> it covered already?
>
Don't know, depends on how you answer to the above point ;-)
>
> Good Idea, thought it's brought up a few questions:
>
> 1. When I do the <control-minis> to Decrease the font size
> I can't undo it with the <control-plus>. Also <control-plus>
> doesn't seem to do anything.
>
> 2. When displaying the "Lane info" why can't I see the
> branch names?
>
Thanks for the reports, I will investigate as soon as I have a bit of
spare time.
>
> I'll read it a few more times. I seem to sometimes get into a state
> where I'm locked onto the current change set and can't get back to
> the other change sets without starting another qgit.
>
Please, could you be so kind to better explain me the above point.
Seems interesting, but I didn't get how to reproduce.
> >
> > Yes it is. There are a lot of new featrures, is almost as stable as
> > the previous and if you are interested in file history (annotations)
> > in qgit-2.0 this feature has been greatly speeded up.
>
> Do you know if it's a lot of work to install Qt4?
>
With Mandriva you are just at an uprmi away.
Try something like
urpmi libqt4-devel
It worked for me ;-)
Marco
^ permalink raw reply
* Re: On Tabs and Spaces
From: Luke Lu @ 2007-10-17 7:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710161722320.26902@woody.linux-foundation.org>
I'm late in this game. But it's too classic a debate to miss the fun.
On Oct 16, 2007, at 5:45 PM, Linus Torvalds wrote:
> One issue may well be that Windows programmers also probably don't
> work
> very much with patches, do they?
>
> One reason for *really* wanting to use hard-tabs is that it makes
> patches
> look better, exactly because diffs contain that one extra (or two,
> in the
> case of old-style context diffs) character at the beginning of the
> line.
>
> Which means that while all-space indents look fine, *mixing* styles
> definitely does not. In particular, a two-character indent (which
> hopefully nobody uses, but people are crazy) will be totally
> unreadable as
> a patch if you have the (fairly common, at least in UNIX projects)
> style
> of using spaces for less-than-eight-character-indents and tabs for the
> full 8 characters.
Yes, all-space would look fine in patches. It'll look better than all
tabs for tables and ascii formula and diagrams in comments, as one
prepended character could screw up the tabs (depending on the
content), rendering them totally unreadable. In all-space case,
things just shift to the right by one character column.
I believe the indentation convention for ruby is 2 spaces. It looks
tight to me :)
> (In particular, a 3-level and 4-level indent will look *identical*
> in such
> a project, when using context diffs).
>
> And sure, you can use all-spaces-everywhere, but that just isn't
> what any
> normal UNIX editors are set up for by default. In contrast, under
> UNIX, I
> can pretty much guarantee that hard-tab indents look at least
> reasonable
> in any editor.
But all-space would look perfect in any editor as the authors
intended, including the tables and ascii arts, as long as it's using
monospace font. It's easy to setup all space editing on all platforms
(Windows, Mac, *nix) It's also much easier to enforce. I've used pre-
commit hook to check for tabs in the source and reject them if a tab
is found :)
> And if you have an editor that shows hard-tabs as 4-character indents,
> generally you can work with it. You may have odd indentation, and
> people
> may complain about your patches not lining up, and yes, it would be
> up to
> *you* to understand that 8-wide tabs are the normal and default.
> But you
> can certainly work with a source base that uses a single hard-tab for
> indentation.
> In contrast, if you use spaces (or worse - mixing), things really look
> ugly as sin, to the point of actually being unworkable.
>
Well, we just established that all-space is perfect, look-wise.
> In short:
>
> - if the project has the rule that an indentation is "one hard-
> tab", then
> at least everybody can *work* with that project. Different
> people may
> see things laid out slightly differently, but it's generally not a
> horrible disaster, especially if you aim to use block comments
> indented
> with the code (like we *mostly* do both in the kernel and in git)
>
> - all-space and all-tabs just leads to problems. Yes, I know about
> python, but lets face it, python is different, since the spacing
> has
> semantic rules there. Most non-python programmers will not use
> editors
> where you can obviously see the difference between spaces and
> tabs, and
> as a result an all-space model will *turn* into a mixed-space/tab
> model, and you get horrible end results.
As I mentioned, an all-space policy is trivial to enforce.
> - as per above, mixing spaces and tabs is a *horrid* idea.
>
> - as a result, a "pure tab for indents" model tends to be workable in
> most situations. It may not be ideal for you, but it's workable.
>
> - and at least in the UNIX world, default for pure tabs really is 8
> characters. Even if you have an editor that shows them as four,
> you'll
> see different results outside the editor (eg "grep -5 file.c"), so
> people should just consider other tab sizes to be "secondary".
>
> And as long as 99% of all git developers are under Linux, and
> all the
> core ones seem to have had no problem with the current tab rules, I
> really don't see why that should change.
>
> See? Hard-tabs are good. Maybe Windows people don't ever see patches
> (perhaps they only see them as side-by-side graphical things), and
> maybe
> windows projects are always done inside *one* environment where
> there is
> no "grep" and "terminal TAB size" and "fifty different editors with
> different defaults".
>
> But even in DOS/Windows, hard-tabs seem to be quite common, judging by
> what little source code I've seen from Windows projects.
>
> And I just checked. The current git model seems to work fine if you
> have
> an editor that thinks tabs are 4 spaces:
>
> sed 's/ / /g' < revision.c | less -S
>
> (that's a hard-tab in that first regex). No, things don't
> necessarily line
> up just like they should, but you actually have to *look* for
> problems to
> see them (ie stuff where people have added line-breaks).
>
> And is it really so unreasonable to just say "8-character tabs are the
> gold standard"?
But I still haven't seen any compelling arguments against the "all
space" case, other than "people will screw it up into mixed spaces",
which is really a straw man, as many multi-platform projects enforced
the all-space policy easily by using a pre-commit hook in
maintainers' repository.
The only downside of all-space is a moderate space bloat in source,
which is insignificant, all things considered.
I agree that "8-character tabs are the gold standard", only for the
tabstop==8 part but not the indent==tab part. For me the question is:
is it really so unreasonable to just say "all-space is the holy grail"?
__Luke
^ permalink raw reply
* Re: git-cherry-pick no longer detecting moved files in 1.5.3.4
From: Richard Quirk @ 2007-10-17 7:18 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200710170035.12482.barra_cuda@katamail.com>
On 10/17/07, Michele Ballabio <barra_cuda@katamail.com> wrote:
> 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.
>
This doesn't work either. Cherry picking is not triggering the loading
of this value at all.
This is because git-cherry-pick turns into a git-merge-recursive. This
calls get_renames() in merge-recursive.c, which calls diff_setup,
setting the renamelimit to -1, then calls diff_setup_done(), which
sets the renamelimit to diff_rename_limit_default since rename_limit
was < 0. diff_rename_limit_default is the hard-coded value of 100. At
no point does merge-recursive call git_diff_ui_config() in diff.c that
reads in the diff.renamelimit user defined value, so in the end the
cherry pick uses the hardcoded value of 100.
^ permalink raw reply
* Re: [PATCH 01/25] Add a simple option parser.
From: Shawn O. Pearce @ 2007-10-17 7:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1192523721-18985-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> wrote:
> The option parser takes argc, argv, an array of struct option
> and a usage string. ...
OK, I've chewed down some version of this series. ;-)
To be more specific I fetched ph/parseopt (11b83dc4da) from your
tree at git://git.madism.org/git.git and split it apart somewhat.
All of the patches were rebased onto my most recent master but I
also yanked the two that impacted the builtin-fetch series out and
layered them over a merge of db/fetch-pack and my version of your
ph/parseopt series.
Why? Well I want to keep our options open about which series
graduates to master first. Although builtin-fetch has been cooking
for a while there's been a number of issues with that code.
There exists a (perhaps small) chance that ph/parseopt will be
ready before db/fetch-pack.
Currently ph/parseopt is in pu. Tomorrow I'll look at the usage
strings in more depth and see if any improvements can be easily
made. I already made one suggested by Dscho in builtin-add.
--
Shawn.
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.
From: Marco Costalba @ 2007-10-17 7:30 UTC (permalink / raw)
To: pete, piet.delaney
Cc: Linus Torvalds, VMiklos, free cycle, git, piet.delaney,
Piet Delaney
In-Reply-To: <47159779.6010502@bluelane.com>
On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
> While I'm looking at the diffs for a file if I pull down External Diff
> it launches 'kcompare' but for a file with a large change it seems
> to be running extremely slow.
qgit does not intergarte Kompare functionality, it just prepares the
files and spawns a Kompare process.
So there's seem nothing qgit can do about Kompare speed. You can try
with different diff viewers, meld,...etc..
> for small files. Know of what can me done so that 'kcompare' works
> fast on large files; something like pointing it's tmp files to a
> not NFS partition.
>
Well temporary file sfor Kompare are created in the repository working
directory. If this is a problem for you you can save manually the
files corresponding to the two revisions you want to diff (open tree
view, select the file, right click to open context menu, save as...)
You need to repeat the above 'save as...' the first time selecting the
first revision you want to compare, then selecting the other revision
in main view, so that tree view is updated and you end-up saving the
correct files.
You can save the files where you want then run Kompare manually, at
least you test your assumption about slowness of NFS partition.
>
> Another problem I've noticed is that sometime while running git
> it seems to spend a large amount of time switching from one
> change-set to the next; seems to be due to all of the tagged
> files.
>
If you can post a repository where this occurs and the step to
reproduce I can investigate further.
> > Another feature you asked, i.e. CTRL + right click to select a
> > revision (different from the parent) to diff against the current one
> > is also already implemented.
>
> It seems that while I'm in "Rev List" mode I can select the the
> two versions to compare a selected file with View->External diff...
>
> Now, if I pull down "View File" or go to the file context were
> you see the change-set for a file then I can't get the CTRL + right
> click to allow me to diff two revisions of the file.
>
Yes. This is true, is not supported this feature. Maybe could be added ;-)
>
> MY guess is that I should install a newer version of qgit,
> I'm using 1.5.3.
>
Please install 1.5.7, it has several bugs fixed.
> How difficult is it to upgrade to the Qt4. Can I just
> install it to /usr/local and not interfere with Qt3?
It does not interfere wuth Qt3 also if you install with urpmi,
directories are kept separated. I have installed both with no
problems.
> Last I recall messing with installing ethereal from src
> I needed a graphics lib and as I recall installing it in
> /usr/local/ confused some build crap. It would be interesting
> to try out your new qgit-2.0.
>
Qt4 is big and complex, I would really suggest avoid experimenting
with that library, stay safe and use urpmi.
> >
> > And of course the two above features can be integrated: you select two
> > random revisions and then call the external diff viewer to check at
> > the differences in the way you prefer.
>
> Right, but how do I do this from the file context?
>
In this case (and also in the above case of external viewer) you need
the magic wand ;-)
Select a file from tree view, go with the magic wand and you can do
everithing from main view.
>
> it seems to be pretty big. The date on 1.5.7 was very
> close to 2.0 so I thought they might be very close in
> functionality and you maintaining the same code for
> both the common Qt3 and the new Qt4 to make it easy
> for users to install.
>
Yes it is. qgit-1.5.7 should be very similar to qgit-2.0 regarding the
features you listed above.
Marco
^ permalink raw reply
* Re: git-cherry-pick no longer detecting moved files in 1.5.3.4
From: Shawn O. Pearce @ 2007-10-17 7:33 UTC (permalink / raw)
To: Richard Quirk; +Cc: Michele Ballabio, git
In-Reply-To: <cac9e4380710170018p26ae8935xc4d3218f4db5411d@mail.gmail.com>
Richard Quirk <richard.quirk@gmail.com> wrote:
> On 10/17/07, Michele Ballabio <barra_cuda@katamail.com> wrote:
> > It should be
> > diff.renamelimit = 0
> >
> > to set the "unlimited" limit.
> >
>
> This doesn't work either. Cherry picking is not triggering the loading
> of this value at all.
>
> This is because git-cherry-pick turns into a git-merge-recursive. This
> calls get_renames() in merge-recursive.c, which calls diff_setup,
> setting the renamelimit to -1, then calls diff_setup_done(), which
> sets the renamelimit to diff_rename_limit_default since rename_limit
> was < 0. diff_rename_limit_default is the hard-coded value of 100. At
> no point does merge-recursive call git_diff_ui_config() in diff.c that
> reads in the diff.renamelimit user defined value, so in the end the
> cherry pick uses the hardcoded value of 100.
That's an "old" bug. Lars Hjemli fixed this in df3a02f612 back on
Sept 25th. You can get the fix from either Junio's or my git tree
in the master branch.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Shawn O. Pearce @ 2007-10-17 7:35 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, Johannes Schindelin, git
In-Reply-To: <20071014142826.8caa0a9f.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> Here is my bisect dunno patch series again.
> The changes since last time are the following:
I now have this series queued in my pu branch. It passes the tests
it comes with, and doesn't appear to break anything, but apparently
there is also still some debate about what a dunno should be called
("unknown", "void", "ugly", "dunno", "skip" ...).
--
Shawn.
^ permalink raw reply
* Re: [PATCH 01/25] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-17 7:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071017072419.GZ13801@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]
On Wed, Oct 17, 2007 at 07:24:19AM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > The option parser takes argc, argv, an array of struct option
> > and a usage string. ...
>
> OK, I've chewed down some version of this series. ;-)
>
> To be more specific I fetched ph/parseopt (11b83dc4da) from your
> tree at git://git.madism.org/git.git and split it apart somewhat.
> All of the patches were rebased onto my most recent master but I
> also yanked the two that impacted the builtin-fetch series out and
> layered them over a merge of db/fetch-pack and my version of your
> ph/parseopt series.
>
> Why? Well I want to keep our options open about which series
> graduates to master first. Although builtin-fetch has been cooking
> for a while there's been a number of issues with that code.
> There exists a (perhaps small) chance that ph/parseopt will be
> ready before db/fetch-pack.
Yes, this makes sense, otoh the migration of the fetch commands are
really independant so you can put those appart, even if I end up needing
to rewrite them it's not an issue.
> Currently ph/parseopt is in pu. Tomorrow I'll look at the usage
> strings in more depth and see if any improvements can be easily
> made. I already made one suggested by Dscho in builtin-add.
wonderful, thanks.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-cherry-pick no longer detecting moved files in 1.5.3.4
From: Richard Quirk @ 2007-10-17 7:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071017073357.GA13801@spearce.org>
On 10/17/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> That's an "old" bug. Lars Hjemli fixed this in df3a02f612 back on
> Sept 25th. You can get the fix from either Junio's or my git tree
> in the master branch.
Yes, with that fix setting the diff.renamelimit config value to 0
really does work. Thanks!
^ 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