* Re: On Tabs and Spaces
From: Sam Ravnborg @ 2007-10-16 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jari Aalto, git
In-Reply-To: <alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org>
On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote:
>
> The answer is *also* not "tabs are just for initial code
> indents", because not only will most sane editors never even show the
> difference, it's simply not how people work. So such a rule about
> invisible things doesn't work.
It is insane to *require* diciplined people to use tabs for more than
code indents.
If you insist on using tabs all over the place - fine with me.
But do not frown upon me and other diciplined people becasue we use
spaces to make sure our arguments to a function call is properly
aligned in a tab=10,tab=8,tab=2 environment.
The arguments "tabs are always 8 spaces properly aligned" is just
to reach the lowest common denominator around developers.
And frankly there are some that do better than that.
The root casue are the stupid editors that does not make it
easy to be diciplined and thats where the errors come from
and all the stupid rules like the above.
Sam
^ permalink raw reply
* Re: remote#branch
From: Jan Hudec @ 2007-10-16 21:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710161139530.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
On Tue, Oct 16, 2007 at 11:49:58 +0100, Johannes Schindelin wrote:
> In related news, I recently thought about the url#branch issue.
>
> There were three arguments against it AFAIR: "#" is a comment marker, and
> this syntax is not extensible to more than one branch names. And that the
> branch name is not really a part of the URL.
>
> Turns out that I am not so sure about the last two issues.
>
> It is easily extensible to more than one branch by remote#branch1#branch2,
> and in a very real sense, this is a resource locator.
>
> And we could replace the "#" by every character that is illegal in ref
> names as well as URLs. I propose SPC. ('#' is allowed in refnames.)
It's a question, whether the branch name is part of the URI, or a fragment.
Current usage suggests it is a fragment, but according to the URL
specification that is supposed to mean that the resource is always accessed
the same (fragment is NOT part of the URL) and the fragment only affects
local handling. Which I don't think is really true.
If it is a fragment, than "#" is the only correct separator and should stay
that way.
If it is not a true fragment, than we might want to phase it out in favor of
something else. But I would strongly prefer staying within characters allowed
in URI (as per rfc2396). We could consider whether the branch is not
a component parameter -- which would imply ";" as separator, but I would vote
against that on the basis that it's shell special. Non-special characters
allowed by URL in this context would be ":", "@", "=", "+", and ",", of which
":" or "@" seem best to me.
As for multiple branches, separating them with "," feels logical to me, no
matter what separates them from the repository path. On the other hand given
that neither ":" nor "@" is allowed in refnames, reusing the same separator
would make sense especially if git switched to either of those.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Some git mv questions
From: Jan Wielemaker @ 2007-10-16 21:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Lars Hjemli, git list
In-Reply-To: <alpine.LFD.0.999.0710161030430.6887@woody.linux-foundation.org>
On Tuesday 16 October 2007 19:34, Linus Torvalds wrote:
> On Tue, 16 Oct 2007, Lars Hjemli wrote:
> > On 10/16/07, Jan Wielemaker <wielemak@science.uva.nl> wrote:
> > > * On a somewhat bigger test I moved a large directory using
> > > "git mv dir newdir" (where newdir is an existing directory).
> > > Now "git status" gives a lot of new and deleted files!?
> >
> > You could try to adjust diff.renameLimit in .git/config
>
> Yes. The default rename limit I did has turned out to be a disaster. It's
> quite common to have more than a 100x100 matrix of deleted files.
>
> For people with any kind of beefy hardware, I'd just suggest doing a
>
> git config --global diff.renamelimit 0
>
> which disables the rename limiting entirely.
>
> There's a related (embarrassing) problem, namely that I think that the
> current released versions (1.5.3.3 and 1.5.3.4) don't honor the
> renamelimit configuration for merging, so if you do merges across renames
> with changes to the renamed files, you need to use either an older git
> that didn't have the rename limit at all (nor any of the speed-ups) or you
> need to use current git from the 'master' branch.
Thanks both of you. I can master that. I understand I only should ensure
to be running the latest version if I start the merge?
Cheers --- Jan
^ permalink raw reply
* Re: [PATCH] cvsexportcommit: get rid of temporary directory
From: Robin Rosenberg @ 2007-10-16 21:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, hjemli, gitster
In-Reply-To: <Pine.LNX.4.64.0710152332230.25221@racer.site>
tisdag 16 oktober 2007 skrev Johannes Schindelin:
>
> Since commit e86ad71fe5f53ae4434566bd09ea4256090e5a3a we do not use
> a temporary directory in cvsexportcommit. So there is no need to set
> one up.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked
Discovered because Wingit made a lot of noise about $tmpdir being used only
once.
-- robin
^ permalink raw reply
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Robin Rosenberg @ 2007-10-16 21:20 UTC (permalink / raw)
To: Michael Witten; +Cc: Johannes Schindelin, git
In-Reply-To: <19B03C18-6BBD-4F67-93DC-37B422445C82@mit.edu>
tisdag 16 oktober 2007 skrev Michael Witten:
>
> On 16 Oct 2007, at 9:04:34 AM, Johannes Schindelin wrote:
>
> > Hi,
> >
> > does --binary hurt?
>
> It's a no op according to the documentation.
>
> In my experience, the healthier the trees are,
> the healthier the forest is.
>
> Michael Witten
So all this series does is... making it harder to follow the history?
Ack for removing the --binary, the rest is just noise, and the remove tempdir
patch should be attributed to Johannes since he wrote the patch (ack to that one
too, which he wrote and submitted exactly two minutes ahead of me, just enough
for me not to submit it.).
-- robin
^ permalink raw reply
* Re: Is there any plan to support partial checkout or submoudule improvement?
From: Jan Hudec @ 2007-10-16 21:33 UTC (permalink / raw)
To: franky; +Cc: 'Johannes Schindelin', 'Lars Hjemli', git
In-Reply-To: <20071016115310.5FB957E6D@mail.kooxoo.com>
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
On Tue, Oct 16, 2007 at 19:53:08 +0800, franky wrote:
> > You are talking as if your partial checkout was a project in its own
> > right. Then make it so. Do not use a partial checkout, but make that a
> > submodule.
>
> As I said in the first email, the submodule way suffers from the multiple
> commit problem: src and bin as two submodules of project, three commits (for
> the 3 dirs separately) are needed when src directory changes and compiled
> binaries being put in bin directory. It's annoying to have to give 3 commit
> logs.
Thinking about it, it's only two commits -- src can be a submodule, but bin
a normal directory (you can choose not to check out subprojects during
repository checkout).
This has the advantage, that bin, even when src is not checked out, always
knows what version of src it is based on (it's in the gitlink) and you only
give two commit messages.
Now I would actually say that commiting bin independently is better.
It allows you to commit sources more often (eg. if you are doing series of
small fixes) and more flexibility for branching (you don't want to merge
binaries).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-16 21:35 UTC (permalink / raw)
To: Jan Hudec; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071016210904.GI26127@efreet.light.src>
Hi,
On Tue, 16 Oct 2007, Jan Hudec wrote:
> If it is a fragment, than "#" is the only correct separator and should
> stay that way.
You did not listen, did you? '#' is allowed in ref names. Therefore this
character really would lock us in to only ever reference _one_ and _only_
one remote branch at a time. This might have worked for cogito, but it
does not for git.
So, I say it again, '#' is _out_.
> If it is not a true fragment, than we might want to phase it out in
> favor of something else. But I would strongly prefer staying within
> characters allowed in URI (as per rfc2396).
If you do that, "http://<xyz-with-branch>" would be ambiguous, wouldn't
it? This would already reference an HTTP resource, and you could not
embed refnames into the URL.
> As for multiple branches, separating them with "," feels logical to me,
> no matter what separates them from the repository path. On the other
> hand given that neither ":" nor "@" is allowed in refnames, reusing the
> same separator would make sense especially if git switched to either of
> those.
',' is allowed in ref names, so ',' is out.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Remove link to the survey from the git home page.
From: Paolo Ciarrocchi @ 2007-10-16 21:57 UTC (permalink / raw)
To: pasky, git
As far as I know the survey is close so it makes sense to remove the link/text from the home page.
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
index.html | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/index.html b/index.html
index 5d14acf..dc5189a 100644
--- a/index.html
+++ b/index.html
@@ -50,7 +50,7 @@ the <a href="http://www.gnu.org/licenses/gpl2.txt">GNU General Public License v2
It was originally written by Linus Torvalds and is currently maintained by
Junio C Hamano.</p>
-<p><strong><a href="http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9">The Git User Survey</a> is up now! Please devote a few minutes of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of GIT, and of course what you don't like of it.</strong></p>
+
<div style="float: right"><table class="releases">
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* [PATCH] Help people in finding the download links
From: Paolo Ciarrocchi @ 2007-10-16 21:58 UTC (permalink / raw)
To: pasky, git
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>
---
index.html | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/index.html b/index.html
index dc5189a..b061178 100644
--- a/index.html
+++ b/index.html
@@ -54,7 +54,7 @@ Junio C Hamano.</p>
<div style="float: right"><table class="releases">
- <tr class="odd" align="center"><td colspan="2"><!--@DATE@-->[2007-10-03]</td></tr>
+ <tr class="odd" align="center"><td colspan="2"><b>Download GIT source package</b> <!--@DATE@-->[2007-10-03]</td></tr>
<tr align="center"><td colspan="2">The latest stable Git release is <b><!--@VNUM@-->v1.5.3.4</b>:</td></tr>
<tr align="center"><td>
<!--@TARLINK@--><a href="http://kernel.org/pub/software/scm/git/git-1.5.3.4.tar.bz2">tar.bz2</a>
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: [PATCH] tail -n not supported in all OSs
From: Theodore Tso @ 2007-10-16 22:06 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
On Tue, Oct 16, 2007 at 07:57:14PM +0300, Jari Aalto wrote:
>
> SunOS/Solaris tail(1) does not support option '-n'. The
> following patches change occurrances of:
>
> tail -n <N>
>
> to
>
> tail <N>
POSIX.2 guarantees that "tail -n 2" works. "Tail -<N>" is considered
obsolete. Unfortunately Solaris requires you to use
/usr/xpg4/bin/tail if you want a POSIX.2 compliant header file. The
/usr/bin/tail is designed for System V R3 compliance (i.e., from a
full two decades ago; SVR3 was released in 1987), and is due to Sun's
vow to Backwards Compatible Forever.
See "man 5 standards" on a Solaris box to see how your PATH variable
has to be set if you want something which is compatible with modern
Unix/Linux common usage.
- Ted
^ permalink raw reply
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Michael Witten @ 2007-10-16 22:13 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200710162320.14917.robin.rosenberg.lists@dewire.com>
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.
Michael Witten
^ permalink raw reply
* Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito
From: Jonas Fonseca @ 2007-10-16 22:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710161139530.25221@racer.site>
On 10/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 16 Oct 2007, Petr Baudis wrote:
> > I'm not sure this is good idea, Cogito is still quite frequently used
> > and it should be documented that it exists.
>
> I agree. But maybe it could be marked as unmaintained? Maybe someone
> steps up to maintain it. Or, even better, comes up with a list of "this
> is what I like do regularly with cogito, but there's no easy way with core
> git" issues.
One thing that I occasionally miss is
cg-export /path/to/directory/
And yes, I know it can be accomplished via "obscurities" like
git-archive+tar (or worse git-checkout-index) but I think having
an easy way to checkout to a directory could be great (and possibly
with the ability to apply substitutions with the recent discussion).
Else, I am really looking forward for the option parser work to provide
an easy way to list options. I found it very useful with Cogito.
Also, most of the "status" commands in Cogito seemd to provide a richer
default output geared towards human consumption. For example stuff like
git-branch -v and git remote -v flags would have been the default for
Cogito ... I think.
--
Jonas Fonseca
^ permalink raw reply
* git-cherry-pick no longer detecting moved files in 1.5.3.4
From: Richard Quirk @ 2007-10-16 22:17 UTC (permalink / raw)
To: git
I recently upgraded from git 1.5.3 to 1.5.3.4 and my cherry picks from
path/to/file.c to path/to/subdir/file.c stopped working. The error being:
CONFLICT (delete/modify): path/to/file.c deleted in HEAD and modified
in 9f944cb... <commit msg> Version 9f944cb... <commit msg> of
path/to/file.c left in tree.
The history of my project is that I had an extra sub directory that I
got rid of, moving files up a level on the master branch but this
extra directory is still present on a "release" branch. It is to this
release branch that I am cherry picking changes from the master one.
This worked fine in 1.5.4.
I tracked the change that scuppered my cherry picking down to this fix
by Linus for rename detection limits:
http://git.kernel.org/?p=git/git.git;a=commit;h=0024a54923a12
Seems like I hit the limit there - the moving changed the location of
about 140 files. I tried setting diff.renamelimit to -1 but to no
avail. Is it that the config value only applies for git-diff, not
git-cherry-pick? (Also, minor thing this, but the docs for git-config
says it is diff.renameLimit but diff.c uses diff.renamelimit.)
Recompiling with diff_rename_limit_default set to -1 in diff.c "fixes"
the cherry picking, but isn't ideal. Anyone have any ideas for a
better workaround/fix?
thanks,
Richard
^ permalink raw reply
* Re: [PATCH 04/25] Rework make_usage to print the usage message immediately
From: Pierre Habouzit @ 2007-10-16 22:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Shawn O. Pearce
In-Reply-To: <20071016175650.GA9992@steel.home>
On Tue, Oct 16, 2007 at 05:56:50PM +0000, Alex Riesen wrote:
> Pierre Habouzit, Tue, Oct 16, 2007 10:39:37 +0200:
> > From: Alex Riesen <raa.lkml@gmail.com>
> >
> > Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> > ---
> > parse-options.c | 48 ++++++++++++++++++++++--------------------------
> > 1 files changed, 22 insertions(+), 26 deletions(-)
>
> Got it three times: you put git@kernel.org into To: and Cc:
sorry, but it's not the reason, I sent it three time, there was a
problem with Shawn O. Pierce, it wasn't escaped properly and VGER ate
the mails because of that.
> Why stderr, BTW? For instance, the output from "git help" is on
> stdout. To be fair, I don't know why it is stdout there either.
because it's what usage() does already ?
>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
^ permalink raw reply
* 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
* [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
* [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] 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
* 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 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: 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
* 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: [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: [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
* [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
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