* [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
* 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
* 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: 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: 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: [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: 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: 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: 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
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