* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Michael Witten @ 2007-10-17 1:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071017011148.GL13801@spearce.org>
On 16 Oct 2007, at 9:11:48 PM, Shawn O. Pearce wrote:
> Sorry, but I have to say I agree with Robin here. The tab patch
> is large, ugly, and provides relatively little value in comparsion.
>
> The first rule of git development typically is "any change is bad".
> Because anything that is already written can be assumed to already
> be tested and in use by someone. Breaking that is bad, as then
> they have a bad experience with git.
OK. I understand.
This was really preparation for a more substantial addition
that I hope to make.
I'll just have to change one line at a time with every substantial
patch!
mfwitten
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Petr Baudis @ 2007-10-17 1:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710141505y75ab61c4l50688fc9530e4f90@mail.gmail.com>
On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> This website itself is tracked in Git as well - you can browse its
> development history or even clone it from
> http://repo.or.cz/r/git-homepage.git. The site is covered by GPLv2 and
> maintained by Petr Baudis who always takes patches eagerly. ;-)
Note that if someone is going to contribute to the homepage more
regularily, I can give him push access as well.
> Here is short summary of most common answers, with a short comment if
> appropriate:
>
> 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)
See my other mail in this thread; if someone registers it, I can set
everything else up.
> # Better design: make it prettier, easier to find information,
> move more important things first, use sidebar instead of boxes,
> perhaps divide it into separate pages (again). But make sure it
> works on Elinks for example.
>
> (IIRC pasky is not web designer, so help is appreciated)
I'm not really unhappy with the current layout - I think it is pretty
enough but simple. Dividing it to separate pages is question of taste
and opinitions simply differ; I personally think with the current amount
of information single page is fine. OTOH I think it would be nicer to
get more content on the page, then perhaps split it up. :-)
Sure, the webpage could be much prettier, with cute graphics and so on.
But I'm not a webdesigner and can't really do these things better than
how they already are. And is it really that bad?
> Documentation
> # More documentation: tutorials, workflow examples, walkthroughs,
> SCM commands comparison, interacting with other SCMs, HOWTOs, best
> practices, recommended tools, fluxograms describing use cases
> (graphics). Make link to Git User's Manual stand out better.
Yes, please! Bring it on! ;-)
> # Less emphasizis on Cogito, mark it more explicitely as deprecated
> and slowly try to get rid of Cogito references in documentation
> (e.g. crash courses).
>
> (Cogito is officially deprecated from not a long time; the process
> of removing references to cg in crash courses is AFAIK ongoing)
Fixed, hopefully?
> # Simple online demo. The demo could be an applet giving access to a
> terminal of a running virtual machine with git and some demo
> repositories. The virtual machine is reset every full hour.
>
> (This might be a good idea, but I think it is a bit hard to do from
> technical point of view; at least securely, securing against
> intrusion and, perhaps accidental, denial of service)
Yes, and I don't think this is all that important since Git should be
readily available pre-packaged on all popular Linux distributions.
> Downloads:
> # More up-to-date about new git versions.
>
> (With one person updating homepage, who is not git maintainer...)
That shouldn't have been a problem since May; there is a script being
run every 4 hours that syncs this up. If the homepage isn't picking a
release up in a timely fashion, that's a bug and I need to know about
it; I didn't notice anything like that yet, though.
> # There should be links to download pu/next/master/maint branches
> tar.gz trees (snapshots) from gitweb.
>
> (The source snapshot part is quite easy to do, but it might
> increase load on kernel.org / repo.or.cz, unless snapshots are
> somehow cached)
Why would anyone want this? Adding extra useless or seldom-used links to
the homepage is actually harmful, the important ones must not get lost
between those.
> # Results of nightly builds and tests.
> Static binaries for other OS (FreeBSD, MacOS X).
>
> (There is a matter of machine park. Somewhere those nightly builds,
> perhaps together with nightly running of test suite, have to run.)
This is not something for the Git homepage itself. If someone volunteers
to run a tinderbox-like thing for Git, cool. I can link to it. ;-)
> # 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?
> # Provide processed man pages to install.
> Provide PDF documentation, at least PDF version of Git User's Manual.
>
> (Having PDF version is quite new; there is no manual.pdf target in
> official Makefile.)
I think it's more appropriate to link to this from inside the k.org Git
Manual site.
> Information, new links, new features
> # Link to the latest release announcement (RelNotes) on download page.
>
> (Links to relnotes are in HTML version of git(7) manpage, but I
> think it is not enough. Happily we _have_ release announcements)
Done.
> # News section, info about where things are goung (roadmap)
>
> (Junio has a hard time maintaining TODO, and git doesn't have
> roadmap AFAICT)
Maybe something like the News section could be nice, but someone else
would have to maintain it.
Then again, what would be the contents? Just aggregating recent
announces? Cc' posting-restricted mailing list on these and link to its
archives, and you will make more people happy.
> # Provide 'A note from the maintainer' as a prominent link probably
> named as 'How the git project is managed and how to participate'
>
> (That is a good idea I think, better than having it on GitWiki.
> We can put direct link to SubmittingPatches nearby.)
Yes, got a patch from Michael Witten for this few days ago, applied now.
Thanks, Michael!
> # Links to more tools, GUIs, version control interface layers.
> A somewhat related request: copy pages like FAQ or Tips and Tricks,
> or discussion about branches from GitWiki when they are mature
> enough.
>
> (For example there was requests to put links to / info about Guilt
> and Giggle on git homepage. Giggle has quite a bit of users among
> GUIs).
I can't remember ever getting a patch. If I missed it, I'm sorry -
please resend.
> Code and design
> * More prominent links to documentation on how to get started with
> GIT.
How much more prominent can you be? :)
> * The layout and the organization of the sections. It's pretty hard
> to know why should I use git just looking at the webpage.
This is one of the things I tried to optimalize the layout to. If it
doesn't work, I'm sorry but I'm not getting it and you need to be more
concrete.
> * Hide the rarer commands and special tricks deeper and emphasize the
> best usage practices.
That's rather about the Git manual?
> * Download link needs to stand out more. The homepage appears rather
> 'flat' that is nothing stands out as more important than the rest.
Maybe this improved a bit today.
> In order of importance, I think there should be:
> 1. Download
> 2. Git Quickstart Guide
> 3. Documentation
Funnily enough, this _is_ the order in which the information flows.
> * The lines are too long. Try to find a better proportion.
The sidebar would help here, I guess. Counter-argument is that sidebar
would take up space for the main content. ;-)
Opinions? Should the lines get a bit shorter? I'd almost agree.
> * It doesn't look like a project home page.
> Mercurial does a better job with the look of their page IMHO.
I actually find Mercurial's homepage much uglier, personally.
> Documentation
Many suggestions here are for the Git manual, actually; that's a good
sign that the integration isn't working so badly after all.
> * 'git for svn/cvs people' could use an overhaul
> (at least they did a few months ago)
> The Git for SVN users tutorial is incomplete and does not explain
> for example how the index works and why it's there. Thus people end
> up thinking that 'svn add' is like 'git add' whereas it's not.
Yes, this would be nice to get improved; however, the surgery needs to
be very careful in order to avoid complicating or confusing things up
too much - I already got few patches that tried, but the end result
wasn't really working well. Maybe the whole crash course should just be
rewritten along the lines of the Git tutorial?
> * Add some material for presenting git to others (slides)
> * 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!
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* [PATCH] gitweb: speed up project listing by limiting find depth
From: Luke Lu @ 2007-10-17 1:13 UTC (permalink / raw)
To: git; +Cc: pasky, Luke Lu
Resubmit patch due to tab/space issue :)
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 11 +++++++++++
2 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..d62357f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -35,6 +35,10 @@ our $GIT = "++GIT_BINDIR++/git";
#our $projectroot = "/pub/scm";
our $projectroot = "++GITWEB_PROJECTROOT++";
+# fs traversing limit for getting project list
+# the number is relative to the projectroot
+our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
+
# target of the home link on top of all pages
our $home_link = $my_uri || "/";
@@ -1509,16 +1513,23 @@ 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)
+ if (tr!/!! - $pfxdepth > $project_maxdepth) {
+ $File::Find::prune = 1;
+ return;
+ }
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: Shawn O. Pearce @ 2007-10-17 1:11 UTC (permalink / raw)
To: Michael Witten; +Cc: Robin Rosenberg, git
In-Reply-To: <561D7B44-9EDE-447B-A751-BE6E3A3AD9CC@mit.edu>
Michael Witten <mfwitten@MIT.EDU> 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.
`git-blame -w` can probably punch through the indentation change
just fine to find the older history. But it does make `git log -p`
damn ugly to read at this point in history. And if you forget the
-w to git-blame, well, then you are really in for some fun for a
few minutes. Lets not mention pickaxe noticing strings removed+added
in this patch either.
> >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.
Sorry, but I have to say I agree with Robin here. The tab patch
is large, ugly, and provides relatively little value in comparsion.
The first rule of git development typically is "any change is bad".
Because anything that is already written can be assumed to already
be tested and in use by someone. Breaking that is bad, as then
they have a bad experience with git.
There needs to be a really good reason behind a change, like the
existing code is already not functioning according to its documented
behavior due to a corner case input. Such things should be changed.
I'm not going to apply the indentation change patch to my tree.
You can try to resubmit it through Junio after he's back online
and accepting patches.
--
Shawn.
^ permalink raw reply
* [PATCH] gitweb: speed up project listing by limiting find depth
From: Luke Lu @ 2007-10-17 1:03 UTC (permalink / raw)
To: git; +Cc: pasky, Luke Lu
Resubmit patch based on feedback from Shawn O. Pearce.
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 11 +++++++++++
2 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..5eb4414 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -35,6 +35,10 @@ our $GIT = "++GIT_BINDIR++/git";
#our $projectroot = "/pub/scm";
our $projectroot = "++GITWEB_PROJECTROOT++";
+# fs traversing limit for getting project list
+# the number is relative to the projectroot
+our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
+
# target of the home link on top of all pages
our $home_link = $my_uri || "/";
@@ -1509,16 +1513,23 @@ 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)
+ if (tr!/!! - $pfxdepth > $project_maxdepth) {
+ $File::Find::prune = 1;
+ return;
+ }
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* Re: git-cherry-pick no longer detecting moved files in 1.5.3.4
From: Shawn O. Pearce @ 2007-10-17 0:58 UTC (permalink / raw)
To: Richard Quirk; +Cc: git
In-Reply-To: <cac9e4380710161517m64ba737dj8711a6ce59b1b69@mail.gmail.com>
Richard Quirk <richard.quirk@gmail.com> wrote:
> (Also, minor thing this, but the docs for git-config
> says it is diff.renameLimit but diff.c uses diff.renamelimit.)
Someone else already responded about how to set this limit, but
I wanted to clarify what the docs vs. the code were doing here.
The docs use camelCase as it is prettier to read multiple words
that useCamelCase than alllowercaselikethis. Internally when we
parse your config file we lowercase the entire string so that the
code can worry only about the lowercase variant. That's why you
see it all lowercase in diff.c, but the docs suggest you to use
the camelCase format.
--
Shawn.
^ permalink raw reply
* Question on git-filter-branch
From: Bill Lear @ 2007-10-17 0:57 UTC (permalink / raw)
To: git
I'm testing out git-filter-branch, as I would like to use it to remove
proprietary information from our repository.
I created a test repo with "sensitive information" in a file 'A', some
other "plain" information, more sensitive stuff in file 'D', a subdirectory
of sensitive information (some of this added on a branch 'branch_1',
some added on master):
% ls -F sensitive
A B C D sensitive_stuff/
I then cloned this repo and tried the filter:
% git clone sensitive sensitive.clone
% cd sensitive.clone
% git filter-branch --index-filter 'git update-index --remove A' HEAD
Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
% ls
A B C D sensitive_stuff
Ok, so it doesn't list the refs, so I do git status:
% git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: A
#
So, it seems to have done something to A, but I don't know what to do
next.
The man page says: "Now, you will get the rewritten history saved in
the branch newbranch (your current branch is left untouched)." Well,
I don't see any new branch created:
% git branch -a
* master
origin/HEAD
origin/branch_1
origin/master
Then next part of the man page counsels that "To set a commit ...",
but I'm not sure if that is what I want to do (I think it is).
However, I'm not sure what the 'graft-id' refers to, or if I'm
supposed to type in the command as specified, especially since this is
followed by this caution: "if the parent string is empty - which
happens when we are dealing with the initial commit - add graftcommit
as a parent". Here, I'm unsure what graftcommit is, most especially
since the use of 'graft' first appears as 'graft-id'...
Could someone help, please?
Bill
^ permalink raw reply
* Re: [PATCH] When renaming config sections delete conflicting sections
From: Shawn O. Pearce @ 2007-10-17 0:55 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20071017003418.GA11013@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> The old behavior of keeping config sections matching the new name caused
> problems leading to warnings being emitted by git-remote when renaming
> branches where information about tracked remote branches differed. To
> fix this any config sections that will conflict with the new name are
> removed from the config file. Update test to check for this.
...
> This command sequence was causing problems for me:
>
> git checkout -b test madcoder/next
> git checkout -b test2 spearce/next
> git branch -M test
Ouch. But this may cause the user to lose what they might consider
important settings relative to the old section named branch.test.
I think in the case you mention above where you are doing a
`branch -M` the user really does want the basic branch properties
to be forced over (branch.$name.remote, branch.$name.merge) but
they probably do not want other branch properties to be removed
or deleted. Or maybe they do.
Its really hard to second guess the user's intent here. I think
its too broad to whack an entire section when renaming. For example
today lets say I do:
cat >.git/config <<EOF
[remote "many"]
url = blah
fetch = refs/heads/master
fetch = refs/heads/next
EOF
$ git config remote.many.fetch refs/heads/pu
Warning: remote.many.fetch has multiple values
cat .git/config
[remote "many"]
url = blah
fetch = refs/heads/master
fetch = refs/heads/next
So we don't blindly replace multi-valued keys just because the
user asked us to. I don't really see a section as being that much
different to warrant a potentially lossy behavior by default.
--
Shawn.
^ permalink raw reply
* Re: revised: [PATCH] Color support added to git-add--interactive.
From: Dan Zwell @ 2007-10-17 0:47 UTC (permalink / raw)
To: Jeff King
Cc: Wincent Colaiuta, Git Mailing List, Jonathan del Strother,
Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071015034338.GA4844@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 4889 bytes --]
Adds color to the prompts and output of git-add--interactive.
-Reads config color.interactive, respects "auto", "true",
"always", and anything else.
-Uses the library Term::ANSIColor, which is included with modern
versions of perl. This is optional, and should not need to be
present if color.interactive is not on.
-Reads color.interactive.<slot>, where slot is "header", "prompt",
or "help", colorizing output accordingly.
Documentation/config.txt is updated to reflect the new keys.
I cannot test this or see how it looks in manpages, however,
as I cannot install the documentation build tools.
Unfortunately, I think the default colors are ugly, but all colors that
are readable on both black and white backgrounds are probably ugly.
This patch does not colorize the diffs, because that is a larger
job, and very distinct from this (simple) task.
Dan
gzipped patch is also attached, just in case.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 971fd9f..17e29e4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -381,6 +381,27 @@ color.diff.<slot>::
whitespace). The values of these variables may be specified as
in color.branch.<slot>.
+color.interactive::
+ When true (or `always`), always use colors in add--interactive.
+ When false (or `never`), never. When set to `auto`, use
+ colors only when the output is to the terminal. Defaults to
+ false.
+
+color.interactive.<slot>::
+ Use customized color for add--interactive output. `<slot>`
+ may be `prompt`, `header`, or `help`, for three distinct types
+ of common output from interactive programs. The values may be a
+ space-delimited combination of up to three of the following:
++
+(optional attribute, optional foreground color, and optional
background) ++
+dark, bold, underline, underscore, blink, reverse, concealed,
+black, red, green, yellow, blue, magenta, cyan, white, on_black,
+on_red, on_green, on_yellow, on_blue, on_magenta, on_cyan, on_white
++
+Note: these are not the same colors/attributes that the
+rest of git supports, but are specific to git-add--interactive.
+
color.pager::
A boolean to enable/disable colored output when the pager is in
use (default is true).
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index be68814..125655b 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,33 @@
use strict;
+my ($use_color, $prompt_color, $header_color, $help_color);
+my $color_config = qx(git config --get color.interactive);
+if ($color_config=~/true|always/ || -t STDOUT &&
$color_config=~/auto/) {
+ $use_color = "true";
+ chomp( $prompt_color = qx(git config --get
color.interactive.prompt) );
+ chomp( $header_color = qx(git config --get
color.interactive.header) );
+ chomp( $help_color = qx(git config --get
color.interactive.help) );
+ $prompt_color ||= "red bold";
+ $header_color ||= "bold";
+ $help_color ||= "blue bold";
+
+ require Term::ANSIColor;
+}
+
+sub print_colored {
+ my $color = shift;
+ my @strings = @_;
+
+ if ($use_color) {
+ print Term::ANSIColor::color($color);
+ print(@strings);
+ print Term::ANSIColor::color("reset");
+ } else {
+ print @strings;
+ }
+}
+
sub run_cmd_pipe {
if ($^O eq 'MSWin32') {
my @invalid = grep {m/[":*]/} @_;
@@ -175,7 +202,7 @@ sub list_and_choose {
if (!$opts->{LIST_FLAT}) {
print " ";
}
- print "$opts->{HEADER}\n";
+ print_colored $header_color,
"$opts->{HEADER}\n"; }
for ($i = 0; $i < @stuff; $i++) {
my $chosen = $chosen[$i] ? '*' : ' ';
@@ -205,7 +232,7 @@ sub list_and_choose {
return if ($opts->{LIST_ONLY});
- print $opts->{PROMPT};
+ print_colored $prompt_color, $opts->{PROMPT};
if ($opts->{SINGLETON}) {
print "> ";
}
@@ -544,7 +571,7 @@ sub coalesce_overlapping_hunks {
}
sub help_patch_cmd {
- print <<\EOF ;
+ print_colored $help_color, <<\EOF ;
y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks
@@ -619,7 +646,7 @@ sub patch_update_cmd {
for (@{$hunk[$ix]{TEXT}}) {
print;
}
- print "Stage this hunk [y/n/a/d$other/?]? ";
+ print_colored $prompt_color, "Stage this hunk
[y/n/a/d$other/?]? "; my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -673,7 +700,7 @@ sub patch_update_cmd {
elsif ($other =~ /s/ && $line =~ /^s/) {
my @split =
split_hunk($hunk[$ix]{TEXT}); if (1 < @split) {
- print "Split into ",
+ print_colored "$header_color",
"Split into ", scalar(@split), " hunks.\n";
}
splice(@hunk, $ix, 1,
@@ -769,7 +796,7 @@ sub quit_cmd {
}
sub help_cmd {
- print <<\EOF ;
+ print_colored $help_color, <<\EOF ;
status - show paths with changes
update - add working tree state to the staged set of changes
revert - revert staged set of changes back to the HEAD version
--
1.5.3.4.207.gc0ee
[-- Attachment #2: color-add--interactive.patch.gz --]
[-- Type: application/x-gzip, Size: 1749 bytes --]
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 0:45 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Tom Tobin, git
In-Reply-To: <20071017015109.303760cc@localhost.localdomain>
On Wed, 17 Oct 2007, Christer Weinigel wrote:
>
> 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.
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.
(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.
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.
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 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"?
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: speed up project listing by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 0:41 UTC (permalink / raw)
To: Luke Lu; +Cc: git, gitster, Petr Baudis
In-Reply-To: <1192580691-14308-1-git-send-email-git@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> diff --git a/Makefile b/Makefile
> index 8db4dbe..b70ba8c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -165,6 +165,7 @@ GITWEB_CONFIG = gitweb_config.perl
> GITWEB_HOME_LINK_STR = projects
> GITWEB_SITENAME =
> GITWEB_PROJECTROOT = /pub/git
> +GITWEB_PROJECT_MAXDEPTH = 2
I'd rather see this default to an unlimited (or maybe insane?) depth.
Current users may be surprised upon upgrading to a more recent git
when their gitweb stops showing projects because the default depth
is too small.
repo.or.cz is up at 3 deep, maybe 4 right now, right Pasky?
I think letting admins control the depth is a good idea, but its
a performance tuning thing and probably shouldn't break existing
setups.
> + # don't traverse too deep (Find is super slow on os x)
> + return if tr!/!! - $pfxdepth > $project_maxdepth && ($File::Find::prune = 1);
I don't do much gitweb hacking, but I usually don't like to find
code that mutates a value as an important side-effect in the middle
of a boolean condition that is used to determine if we are breaking
out of this function now, or falling through to do more work. yea
its more lines of code but I think it would be easier to grok if this
was a proper if {...}.
--
Shawn.
^ permalink raw reply
* [PATCH] When renaming config sections delete conflicting sections
From: Jonas Fonseca @ 2007-10-17 0:34 UTC (permalink / raw)
To: git, Shawn O. Pearce
The old behavior of keeping config sections matching the new name caused
problems leading to warnings being emitted by git-remote when renaming
branches where information about tracked remote branches differed. To
fix this any config sections that will conflict with the new name are
removed from the config file. Update test to check for this.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
config.c | 9 ++++++++-
t/t1300-repo-config.sh | 17 +++++++++++++++++
2 files changed, 25 insertions(+), 1 deletions(-)
This command sequence was causing problems for me:
git checkout -b test madcoder/next
git checkout -b test2 spearce/next
git branch -M test
On top of spearce/next ...
diff --git a/config.c b/config.c
index dc3148d..578849a 100644
--- a/config.c
+++ b/config.c
@@ -1013,6 +1013,14 @@ int git_config_rename_section(const char *old_name, const char *new_name)
; /* do nothing */
if (buf[i] == '[') {
/* it's a section */
+ remove = 0;
+ if (new_name != NULL
+ && section_name_match (&buf[i+1], new_name)) {
+ /* Remove any existing occurences of the
+ * new section. */
+ remove = 1;
+ continue;
+ }
if (section_name_match (&buf[i+1], old_name)) {
ret++;
if (new_name == NULL) {
@@ -1026,7 +1034,6 @@ int git_config_rename_section(const char *old_name, const char *new_name)
}
continue;
}
- remove = 0;
}
if (remove)
continue;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1d2bf2c..63b969e 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -419,6 +419,23 @@ EOF
test_expect_success "section was removed properly" \
"git diff -u expect .git/config"
+cat > .git/config << EOF
+[branch "new-name"]
+ x = 1
+[branch "old-name"]
+ y = 1
+EOF
+
+test_expect_success "rename and remove old section" \
+ 'git config --rename-section branch.old-name branch.new-name'
+
+cat > expect << EOF
+[branch "new-name"]
+ y = 1
+EOF
+
+test_expect_success "rename and remove succeeded" "git diff expect .git/config"
+
rm .git/config
cat > expect << EOF
--
1.5.3.4.1206.g5f96-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] gitweb: Provide title attributes for abbreviated author names.
From: David Symonds @ 2007-10-17 0:34 UTC (permalink / raw)
To: pasky; +Cc: git, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
gitweb/gitweb.perl | 34 +++++++++++++++++++++++++++++-----
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b2bae1b..3112fd4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3461,9 +3461,15 @@ sub git_shortlog_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 10);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
# git_summary() used print "<td><i>$co{'age_string'}</i></td>\n" .
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
print format_subject_html($co{'title'}, $co{'title_short'},
href(action=>"commit", hash=>$commit), $ref);
@@ -3511,9 +3517,15 @@ sub git_history_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ # shortlog uses chop_str($co{'author_name'}, 10)
+ my $author = chop_str($co{'author_name'}, 15, 3);
+ if ($author ne $co{'author_name'}) {
+ "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- # shortlog uses chop_str($co{'author_name'}, 10)
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
# originally git_history used chop_str($co{'title'}, 50)
print format_subject_html($co{'title'}, $co{'title_short'},
@@ -3667,8 +3679,14 @@ sub git_search_grep_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}), -class => "list subject"},
esc_html(chop_str($co{'title'}, 50)) . "<br/>");
@@ -5181,8 +5199,14 @@ sub git_search {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}),
-class => "list subject"},
--
1.5.3.1
^ permalink raw reply related
* Re: Git User's Survey 2007 summary - git homepage improvements
From: david @ 2007-10-17 0:36 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jan Hudec, Frank Lichtenheld, Jakub Narebski, git,
Jonas Fonseca
In-Reply-To: <20071017002648.GH13801@spearce.org>
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
>>> On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
>>>> On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
>>>>> Generic:
>>>>> # Dedicated domain name / site name, e.g. git.org or git.com
> ...
>>>> (And I guess something like git-scm.org wouldn't qualify as more
>>>> "official", would it?)
>>>
> ...
>> If someone trustworthy in the community has the resources to sponsor the
>> domain, I will only be happy and gladly set it up on my side (I can run
>> the nameservers myself too, if required). But I don't have the
>> resources for registering the domain myself, unfortunately.
>
> "git" is a three letter word. I don't think there have been *any*
> three letter .com/.org/.net domains available for years.
>
> I see that Jonas Fonseca registered git-scm.org today... I wonder
> what his plans are for that domain...
I've been useing the .hm domain for several years. some people who don't
know what it means read it as 'home'. I see that git.hm is not allocated.
David Lang
^ permalink raw reply
* [PATCH] gitweb: speed up project listing by limiting find depth
From: Luke Lu @ 2007-10-17 0:24 UTC (permalink / raw)
To: git; +Cc: gitster, Luke Lu
Resubmit patch to make project max depth configurable.
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 8 ++++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8db4dbe..b70ba8c 100644
--- a/Makefile
+++ b/Makefile
@@ -165,6 +165,7 @@ GITWEB_CONFIG = gitweb_config.perl
GITWEB_HOME_LINK_STR = projects
GITWEB_SITENAME =
GITWEB_PROJECTROOT = /pub/git
+GITWEB_PROJECT_MAXDEPTH = 2
GITWEB_EXPORT_OK =
GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
@@ -831,6 +832,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
-e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
-e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
+ -e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
-e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
-e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
-e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3064298..1453101 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -35,6 +35,10 @@ our $GIT = "++GIT_BINDIR++/git";
#our $projectroot = "/pub/scm";
our $projectroot = "++GITWEB_PROJECTROOT++";
+# fs traversing limit for getting project list
+# the number is relative to the projectroot
+our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
+
# target of the home link on top of all pages
our $home_link = $my_uri || "/";
@@ -1509,16 +1513,20 @@ sub git_get_projects_list {
# remove the trailing "/"
$dir =~ s!/+$!!;
my $pfxlen = length("$dir");
+ my $pfxdepth = ($dir =~ tr!/!!);
File::Find::find({
follow_fast => 1, # follow symbolic links
follow_skip => 2, # ignore duplicates
+ no_chdir => 1, # don't chdir into every directory
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
return if (m!^[/.]$!);
# only directories can be git repositories
return unless (-d $_);
+ # don't traverse too deep (Find is super slow on os x)
+ return if tr!/!! - $pfxdepth > $project_maxdepth && ($File::Find::prune = 1);
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Shawn O. Pearce @ 2007-10-17 0:26 UTC (permalink / raw)
To: Petr Baudis
Cc: Jan Hudec, Frank Lichtenheld, Jakub Narebski, git, Jonas Fonseca
In-Reply-To: <20071017000526.GG18279@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> > On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > > Generic:
> > > > # Dedicated domain name / site name, e.g. git.org or git.com
...
> > > (And I guess something like git-scm.org wouldn't qualify as more
> > > "official", would it?)
> >
...
> If someone trustworthy in the community has the resources to sponsor the
> domain, I will only be happy and gladly set it up on my side (I can run
> the nameservers myself too, if required). But I don't have the
> resources for registering the domain myself, unfortunately.
"git" is a three letter word. I don't think there have been *any*
three letter .com/.org/.net domains available for years.
I see that Jonas Fonseca registered git-scm.org today... I wonder
what his plans are for that domain...
--
Shawn.
^ permalink raw reply
* Re: What's in git/spearce.git (stable)
From: Shawn O. Pearce @ 2007-10-17 0:09 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200710162228.12680.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
> On Tuesday 16 October 2007, Shawn O. Pearce wrote:
> > * The 'maint' branch has these fixes since the last announcement.
>
> There are typos in RelNotes-1.5.3.5.txt:
>
> s/wilh/will
> s/Documention/Documentation
Gah. That'll teach me to not spellcheck a documentation file before
pushing it. :-)
Thanks for catching it.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Petr Baudis @ 2007-10-17 0:05 UTC (permalink / raw)
To: Jan Hudec; +Cc: Frank Lichtenheld, Jakub Narebski, git
In-Reply-To: <20071016201247.GH26127@efreet.light.src>
On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > Generic:
> > > # Dedicated domain name / site name, e.g. git.org or git.com
> > > to have it look less like mirror or unofficial page
> > >
> > > (git.or.cz still comes first when searching Google for "git";
> > > current domain name was available to homepage admin - historical
> > > reason)
> >
> > Hmm, I guess most names that would qualify are already taken
> > (most of them by squatters, though). So someone
> > would have to pay money for this...
> > (And I guess something like git-scm.org wouldn't qualify as more
> > "official", would it?)
>
> It certainly would. It would be 2nd level domain, not a 3rd level one.
>
> Note, that none of the other vcs' have a homepage at theirname.org --
> subversion is svn.tigris.org, bazaar is bazaaz-vcs.org, mercurial is
> www.selenic.com/mercurial, svk is svk.bestpractical.com, monotone is
> monotone.ca. So git-vcs.org would be quite good.
If someone trustworthy in the community has the resources to sponsor the
domain, I will only be happy and gladly set it up on my side (I can run
the nameservers myself too, if required). But I don't have the
resources for registering the domain myself, unfortunately.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-16 23:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710161559150.6887@woody.linux-foundation.org>
On Tue, 16 Oct 2007 16:05:34 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> I do indeed. I don't think it's sensible. And I did think I already
> answered that issue by talking about how most editors don't even
> support it or show the difference between tabs and spaces.
>
> For example, the editor I use - microemacs - supports tabs just fine.
> It does auto-indentation etc. But it does it with hard-tabs by
> default, so now you have to have some editor-specific setup for that
> particular project if you ever want to do anything else.
>
> And that's really what it boils down to. Everybody support
> 8-character hardtabs (and usually by default). They may support other
> things *too*, but any time you move away from that standard
> behaviour, you'll most likely find something that doesn't support the
> alternatives.
Unfortunately most editors are totally confused about the difference
between tab size and indentation level. Visual Studio, probably the
most commonly used development environment on Windows, by default uses
TAB characters that are 4 spaces wide, and users are recommended
not to change that because of that a lot of existing Windows source code
and examples uses those settings.
Two years ago, when I last looked at it, Eclipse, a very commonly used
development environment, managed to confuse tabs and indentation and
make it almost impossible to write Java or C code with a tab size of 8
with a different indentation level. The Eclipse 3 betas did see some
improvement there, I think it got possible to do the right thing in
Java at least, but the normal text editor and C editor lagged behind.
But it was still a big mess and it was much too easy for someone to get
a tab size which is not 8. Hopefully this has been fixed by now, but I
wouldn't bet any significant amount of money on it.
Nedit (which runs on Linux) has a very confusing settings dialog with
terms such as "tab spacing", "emulated tabs". I guess emulated tabs
means the indentation level, but guess how easy that is to mess up.
gedit can control the tab width, but has no setting at all for
configuring the indentation level. Guess what people do when they want
a 4 space indentation level? Yes, right, change the tab size to 4.
A a former colleague who used visual slickedit usually produced code
with tab size 4. I think I've gotten the same crap from ultra edit 32
users.
And so on... Mercifully, _all_ of these editors have a setting to use
spaces instead of tabs, and telling people to turn on that setting is
the absolutely easiest way of making things "just work". Yes, I know,
the correct answer is to tell people to always use tab size 8, and I
frequently and loudly do that. But at the same time, perfect is the
enemy of good. It's much easier to explain "tabs will act differently
in different editors, but if you always us spaces it will not be a
problem" than to get into a discussion about the semantic difference
between tab size and indentation.
If you assume that everyone is sane and use a tab size of 8 you will
get bitten, sooner or later. Or actually, you, Linus, who are lucky
enough to work mostly with Linux source, you might personally not get
bitten all that often. But us poor suckers that have to work with
other people, often Windows programmers, we do.
/Christer
^ permalink raw reply
* Re: [PATCH] Help people in finding the download links
From: Petr Baudis @ 2007-10-17 0:01 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20071016235828.380f70a3@paolo-desktop>
On Tue, Oct 16, 2007 at 11:58:28PM +0200, Paolo Ciarrocchi wrote:
> I believe that with the following change it's a bit easier to visualize the table including the links to the tar.bz2 and tar.gz source packages.
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Thanks, applied.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: Alternative git logo and favicon
From: Petr Baudis @ 2007-10-16 23:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20071016234642.GD18279@machine.or.cz>
On Wed, Oct 17, 2007 at 01:46:42AM +0200, Petr Baudis wrote:
> Before anyone asks, I'm not against changing the logo on Git Homepage,
Darn, never mind this mail. It's all Dscho's fault because he confused
me on IRC! ;-) I didn't notice the date of this thread.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Alternative git logo and favicon
From: Petr Baudis @ 2007-10-16 23:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f62h37$1jn$1@sea.gmane.org>
On Fri, Jun 29, 2007 at 10:49:41AM +0200, Jakub Narebski wrote:
> [Cc: git@vger.kernel.org]
>
> Henrik Nyh wrote:
>
> > I came up with an alternative logo/favicon to use with my gitweb:
> > http://henrik.nyh.se/2007/06/alternative-git-logo-and-favicon.
> >
> > Thought I'd sent it to the list in case someone else likes them.
>
> Added to http://git.or.cz/gitwiki/GitRelatedLogos
>
> But for me logo is too big and wrong proportions for gitweb (although quite
> nice for git pages, I guess), and as favicon it is a bit unreadable.
Before anyone asks, I'm not against changing the logo on Git Homepage,
but before that there should be a clear consensus in the community that
$logo is better than what we currently have. Also, I think we should
strive for consistency here. I think it might be actually good to have
different logo for Git itself and another for Gitweb, but they should be
graphically similar.
I quite like Henrik's logo, but I have to admit that I got rather used
to the old one. ;-) Also, one major problem I have with it is that it
has too little contrast, the colors used seem too light to me and my eye
can't find any "support" inside the logo. This is even much worse with
the favicon where the logo isn't clearly visible on the white background
at all.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Shawn O. Pearce @ 2007-10-16 23:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710161209480.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> first let me thank you for being the interim maintainer. I know it is
> much work, and I frankly do not have the time, or nerve, to do it.
Heh. In the past 24 hours I've really learned how much I appreciate
the work that Junio does, and how infrequently I make it known that
I'm happy he's doing it for us. Nothing like understanding what
the guy goes through then to walk a day in his shoes. :-)
> Out of
> curiousity: did you use the scripts in "todo" to send these emails?
Yes. Took me a few minutes to figure out which scripts did
what magic. Junio likes two character script names, because uh,
they are short to type. Then I hand modified the output to say
git/spearce.git and appear from me, not Junio. But otherwise they
are the same scripts available from his Meta repository (aka the
todo branch).
> On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
>
> > * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
>
> AFAIR this was ready to go to master, with a 5-10% speedup or so, just
> needing a bit of testing. Which it should have gotten by now.
OK. I'll look at it tomorrow and consider moving it. I recall the
context of this discussion now that you mention it, and I've been
running this in production use since Junio committed it to next
so I'm certainly not seeing any downsides to having this patch in
the tree.
> > * kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
> > * js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
Thanks for the summary on these two topics. They are going to stay
parked in next for a while then. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] GIT home page. Mentioning that Cogito is no longer maintained.
From: Petr Baudis @ 2007-10-16 23:38 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20071016195425.016cacbe@paolo-desktop>
On Tue, Oct 16, 2007 at 07:54:25PM +0200, Paolo Ciarrocchi wrote:
> As discussed on the git mailing list
>
> http://marc.info/?l=git&m=119252168629733&w=2
>
> it seems to be a good idea to mention on the git home page that cogito
> is no longer maintained.
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Thanks. In the end, I've chosen a different formulation that should be
shorter and convey the same.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* [PATCH] Fix setup_git_directory_gently() with relative GIT_DIR & GIT_WORK_TREE
From: Johannes Schindelin @ 2007-10-16 23:37 UTC (permalink / raw)
To: git, spearce, gitster
There are a few programs, such as config and diff, which allow running
without a git repository. Therefore, they have to call
setup_git_directory_gently().
However, when GIT_DIR and GIT_WORK_TREE were set, and the current
directory was a subdirectory of the work tree,
setup_git_directory_gently() would return a bogus NULL prefix.
This patch fixes that.
Noticed by REPLeffect on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
setup.c | 13 ++++++++++++-
t/t1501-worktree.sh | 9 +++++++++
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 06004f1..145eca5 100644
--- a/setup.c
+++ b/setup.c
@@ -227,9 +227,20 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (PATH_MAX - 40 < strlen(gitdirenv))
die("'$%s' too big", GIT_DIR_ENVIRONMENT);
if (is_git_directory(gitdirenv)) {
+ static char buffer[1024 + 1];
+ const char *retval;
+
if (!work_tree_env)
return set_work_tree(gitdirenv);
- return NULL;
+ retval = get_relative_cwd(buffer, sizeof(buffer) - 1,
+ get_git_work_tree());
+ if (!retval || !*retval)
+ return NULL;
+ set_git_dir(make_absolute_path(gitdirenv));
+ if (chdir(work_tree_env) < 0)
+ die ("Could not chdir to %s", work_tree_env);
+ strcat(buffer, "/");
+ return retval;
}
if (nongit_ok) {
*nongit_ok = 1;
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 7322161..7ee3820 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -103,4 +103,13 @@ test_expect_success 'repo finds its work tree from work tree, too' '
test sub/dir/tracked = "$(git ls-files)")
'
+test_expect_success '_gently() groks relative GIT_DIR & GIT_WORK_TREE' '
+ cd repo.git/work/sub/dir &&
+ GIT_DIR=../../.. GIT_WORK_TREE=../.. GIT_PAGER= \
+ git diff --exit-code tracked &&
+ echo changed > tracked &&
+ ! GIT_DIR=../../.. GIT_WORK_TREE=../.. GIT_PAGER= \
+ git diff --exit-code tracked
+'
+
test_done
--
1.5.3.4.1223.ga973c
^ permalink raw reply related
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