* Re: [PATCH] gitweb.cgi: Customization
From: Junio C Hamano @ 2006-08-02 17:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060802165333.GA22726@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Why don't we have sensible compile-time defaults that can be overridden
> by a run-time config file like every other sane program?
I like that approach.
^ permalink raw reply
* Re: kompare won't parse git diffs
From: Jakub Narebski @ 2006-08-02 18:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0608021006150.4168@g5.osdl.org>
Linus Torvalds wrote:
> On Wed, 2 Aug 2006, Andy Parkins wrote:
>>
>> Kompare just shows blank for diffs redirected from git. [ snip ]
>>
>> As you can see, it's a simple addition of the line "blah". Kompare shows this
>> diff as blank. Now if I modify the file so that the "---" and "+++" lines
>> both have "<tab>(something)" added:
>
> I'd definitely call this a pure kompare bug.
>
> Not only is the git patch format perfectly standard and accepted by other
> tools, it's much better designed than the brain-damaged syntax that GNU
> patch uses (which adds a tab and a timestamp after the filenames). In
> particular, with git patches it is easy to get filenames that have spaces
> and tabs in them right.
What about filenames with end-of-line character in them? Is it quoted?
BTW. It should be not that hard to get filename with spaces and tabs even
in GNU diff format: everything up to last <tab> is filename.
> Now, if the kompare people can show that every single other patch
> generator adds the stupid tab + date format, I guess we could do it too,
> but
> (a) there is no valid date in general to use, so it's a fundamentally
> broken notion and
Meaning we don't save timestamp in git ;-) Well, we could use date of the
commit which created given file contents (first commit from root, or last
from head which contains given version)... but the same contents might be
introduced independently in different commits. And different clones of the
same repository might have different commit dates...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 9/10] Remove cmd_usage() routine and re-organize the help/usage code.
From: Junio C Hamano @ 2006-08-02 18:18 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060802132149.GG16364@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> On Wed, Aug 02, 2006 at 02:03:44AM +0100, Ramsay Jones wrote:
>> builtin-help.c | 54
>> +++++++++++++++++++++++-------------------------------
>> builtin.h | 7 ++-----
>> git.c | 7 +++++--
>> 3 files changed, 30 insertions(+), 38 deletions(-)
>
> this patch is at the tip of "master" now, but with one more change:
>...
> diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
> index bf1d638..34a3ccd 100755
> --- a/t/t9100-git-svn-basic.sh
> +++ b/t/t9100-git-svn-basic.sh
>...
> this looks strange.
Ramsay's patch to cmd_help() broke this test because the test
relied on the details of output from "git help", which the patch
subtly changed.
I considered making the fix for broken test a separate commit,
but the fix for the test was simple enough, so I rolled it in,
with the additional comment in the log to explain what was going
on -- I suspect the explanation was not clear enough.
I could have committed the fix for the test first and then this
one.
^ permalink raw reply
* Re: kompare won't parse git diffs
From: Andy Parkins @ 2006-08-02 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0608021006150.4168@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]
On Wednesday 2006, August 02 18:19, Linus Torvalds wrote:
> I'd definitely call this a pure kompare bug.
Me too, but it seemed such a small thing change to git that I thought I'd
mention it.
> Not only is the git patch format perfectly standard and accepted by other
> tools, it's much better designed than the brain-damaged syntax that GNU
> patch uses (which adds a tab and a timestamp after the filenames). In
> particular, with git patches it is easy to get filenames that have spaces
> and tabs in them right.
The only three things I checked were diff, git and subversion. git is the
only one of the three that didn't include anything after the filenames.
Subversion uses the space to write (working copy) and (revision XXX), so it's
clear that these fields are simply being treated as commentary. That only
adds weight to the argument that it is a kompare bug, as surely <nil> is a
perfectly acceptable comment?
> Now, if the kompare people can show that every single other patch
> generator adds the stupid tab + date format, I guess we could do it too,
> but
As it seems to be acceptable to put something other than a date, perhaps the
hash of the object being compared would be more useful than the unavailable
date?
> (b) I'm pretty sure that the kompare people only ever actually tested
> with GNU patch or other very modern patches, because when I did the
I'm sure that that is true. I certainly don't think that there is a fight
here, I've not seen any feedback on the kompare bug yet, but I'd be very
surprised if the response is "git is stupid - WONTFIX".
> I'm hoping that people will some day just wake up and notice that the git
> extended patches are really worth doing even for other projects. I was
I think in the cases I've been testing, the extended format hasn't shown its
face. I used git-svnimport to duplicate an svn repository then copied the
same changes into both an svn working directory and a git working directory.
I then ran "git diff" and "svn diff", and diffed the two outputs. Apart from
some differences in how many lines where added and deleted (and the
difference that started this thread of course) the two diffs were equivalent.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH 8/10] Fix some minor warnings to allow -Werror.
From: Ramsay Jones @ 2006-08-02 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvepbvauo.fsf@assigned-by-dhcp.cox.net>
On Wed, 2006-08-02 at 8:46, Junio C Hamano wrote:
>
> "Ramsay Jones" <ramsay@ramsay1.demon.co.uk> writes:
>
> > diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> > index 3e40747..bb5e7b7 100644
> > --- a/builtin-mailinfo.c
> > +++ b/builtin-mailinfo.c
> > @@ -531,7 +531,8 @@ static int decode_b_segment(char *in, ch
> > static void convert_to_utf8(char *line, char *charset)
> > {
> > #ifndef NO_ICONV
> > - char *in, *out;
> > + const char *in;
> > + char *out;
> > size_t insize, outsize, nrc;
> > char outbuf[4096]; /* cheat */
> > static char latin_one[] = "latin1";
>
> This kills the compilation with:
>
> gcc -o builtin-mailinfo.o -c -O2 -Werror -ansi -pedantic -std=c99
> -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wall
> -Wdeclaration-after-statement -g -DSHA1_HEADER='<openssl/sha.h>'
> -DNO_STRLCPY builtin-mailinfo.c
> cc1: warnings being treated as errors
> builtin-mailinfo.c: In function 'convert_to_utf8':
> builtin-mailinfo.c:561: warning: passing argument 2 of 'iconv'
> from incompatible pointer type
>
> where the line 561 reads:
>
> nrc = iconv(conv, &in, &insize, &out, &outsize);
>
OK, so I get exactly the same if I don't make the indicated change!
The second param of iconv() must have changed from const char* to char*
at some point in the last six years.
Just ignore this.
> > diff --git a/diff.c b/diff.c
> > index 5a71489..81630c0 100644
> > --- a/diff.c
> > +++ b/diff.c
> > @@ -614,6 +614,7 @@ static void emit_binary_diff(mmfile_t *o
> > * whichever is smaller.
> > */
> > delta = NULL;
> > + orig_size = 0;
> > deflated = deflate_it(two->ptr, two->size, &deflate_size);
> > if (one->size && two->size) {
> > delta = diff_delta(one->ptr, one->size,
>
> This is not wrong per se, but is working around a stupid compiler that
> do not understand the dataflow. orig_size is only used when
> delta is non NULL, and when delta is non NULL, the variable is
> always set. Not very happy but is acceptable.
>
Yes, you are absolutely correct. I agree it would be nice if gcc was
"fixed" so that it could detect this situation, but I'm not going to
hold my breath. It just seemed to be the lesser evil.
Ramsay
^ permalink raw reply
* RE: [PATCH 6/10] Fix header breakage with _XOPEN_SOURCE.
From: Ramsay Jones @ 2006-08-02 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsfjvaul.fsf@assigned-by-dhcp.cox.net>
On Wed, 2006-08-02 at 8:46, Junio C Hamano wrote:
>
> "Ramsay Jones" <ramsay@ramsay1.demon.co.uk> writes:
>
> > convert-objects.c sets _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED before
> > including <time.h>, in order to get the declaration of strptime().
> > This leads to breakage in cache.h, due to S_ISLNK and S_IFLNK no longer
> > being defined by <sys/stat.h>. These definitions are protected by the
> > __USE_BSD symbol, which is not set when _XOPEN_SOURCE is set. Moving
> > the #defines and #include <time.h> below all other #includes does not
> > fix the problem, however, since now _USE_XOPEN, which protects the
> > declaration of strptime(), is now not defined (don't ask!).
>
> Wouldn't including "cache.h" and friends first and including
> <time.h> last solve the problem, then?
>
Not for me. It may be a glibc 2.1 specific problem, of course, but
strptime() remains undeclared.
> This kind of change tends to fix one system while potentially
> breaking another, and we would need to be careful. Will queue
> for post 1.4.2 and have people scream if it breaks somebody, I
> guess.
>
Yes, I had some concern about that myself. Unfortunately, you can't
make it conditional on the glibc version macros; in order to get the
macros, you have to include (one way or another) <features.h>, at which
point it is already too late ...
Ramsay
^ permalink raw reply
* RE: [PATCH 9/10] Remove cmd_usage() routine and re-organize the help/usage code.
From: Ramsay Jones @ 2006-08-02 18:47 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060802132149.GG16364@admingilde.org>
On Wed, 2006-08-02 at 14:22 Martin Waitz wrote:
> hoi :)
>
> On Wed, Aug 02, 2006 at 02:03:44AM +0100, Ramsay Jones wrote:
> > builtin-help.c | 54
> > +++++++++++++++++++++++-------------------------------
> > builtin.h | 7 ++-----
> > git.c | 7 +++++--
> > 3 files changed, 30 insertions(+), 38 deletions(-)
>
> this patch is at the tip of "master" now, but with one more change:
> builtin-help.c | 54
> ++++++++++++++++++++--------------------------
> builtin.h | 7 ++----
> git.c | 7 ++++--
> t/t9100-git-svn-basic.sh | 7 +++---
> 4 files changed, 33 insertions(+), 42 deletions(-)
>
> diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
> index bf1d638..34a3ccd 100755
> --- a/t/t9100-git-svn-basic.sh
> +++ b/t/t9100-git-svn-basic.sh
> @@ -170,7 +170,7 @@ then
> test -L $SVN_TREE/exec-2.sh"
>
> name='modify a symlink to become a file'
> - git help > help || true
> + echo git help > help || true
> rm exec-2.sh
> cp help exec-2.sh
> git update-index exec-2.sh
>
> this looks strange.
>
Erm, well maybe. I dunno. Junio?
Ramsay
^ permalink raw reply
* Re: kompare won't parse git diffs
From: Junio C Hamano @ 2006-08-02 19:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Paul Eggert
In-Reply-To: <eaqpt2$ots$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> Not only is the git patch format perfectly standard and accepted by other
>> tools, it's much better designed than the brain-damaged syntax that GNU
>> patch uses (which adds a tab and a timestamp after the filenames). In
>> particular, with git patches it is easy to get filenames that have spaces
>> and tabs in them right.
>
> What about filenames with end-of-line character in them? Is it quoted?
You could have done a bit of homework yourself to find that out
easily ;-). Anyway, the answer is yes.
http://marc.theaimsgroup.com/?l=git&m=112927316408690
I wonder what happened to the plan to update GNU diff/patch to
also emit/understand the c-style quoted paths. Paul?
^ permalink raw reply
* Re: kompare won't parse git diffs
From: Linus Torvalds @ 2006-08-02 19:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eaqpt2$ots$1@sea.gmane.org>
On Wed, 2 Aug 2006, Jakub Narebski wrote:
>
> What about filenames with end-of-line character in them? Is it quoted?
I would _not_ guarantee that git handles filenames with newlines in them
correctly in all cases (I won't guarantee tabs either, but the likelihood
is much higher ;). But yes, "git diff" does handle it right.
That said, yes, it should be quoted. A quoted filename in "git diff" not
only changes a newline into the normal quoted sequence (ie "\n"), but will
also put the whole filename in quotes.
So if you have a file called "hello", the diff headers will say
--- a/hello
+++ b/hello
but if you have a file with an embedded newline, it would look something
like
--- "a/hello\nthere"
+++ "b/hello\nthere"
(where a '"' in a filename causes the same quoting to take effect, so if
you haev embedded double-quotes in a filename, it would be shown as
something like
--- "a/embedded\"quote"
+++ "b/embedded\"quote"
instead).
> BTW. It should be not that hard to get filename with spaces and tabs even
> in GNU diff format: everything up to last <tab> is filename.
That's true _if_ you know that the patch was generated by GNU diff, but
since you can't know that (since GNU diff doesn't add any markers of its
own), you cannot know if it's a patch generated by an old version of diff
(for a filename with a tab inside of it) or if it's a filename with the
GNU date extensions.
> > Now, if the kompare people can show that every single other patch
> > generator adds the stupid tab + date format, I guess we could do it too,
> > but
> > (a) there is no valid date in general to use, so it's a fundamentally
> > broken notion and
>
> Meaning we don't save timestamp in git ;-) Well, we could use date of the
> commit which created given file contents (first commit from root, or last
> from head which contains given version)... but the same contents might be
> introduced independently in different commits. And different clones of the
> same repository might have different commit dates...
Exactly, a "date" in _any_ distributed SCM makes no sense what-so-ever.
What happens across a merge? Which date do you take? Do you follow the
thing down and basically do a full "annotate" on the file?
The fact is, dates in SCM diffs are insane and stupid. They do not make
sense in the presense of an SCM, and they only make sense on individual
_files_ (and quite limited there too, but at least it has _some_ meaning).
In the SCM, the _changes_ may have timestamps, but the files sure as hell
should not. Of course, a file-based SCM easily gets confused about these
things (eg in CVS, there is very much a 1:1 relationship between files and
changes, so in the CVS mindset it can make sense - but that's because CVS
is stupid to begin with, and the problem really goes much deeper than
timestamps on the diffs).
Linus
^ permalink raw reply
* [PATCH] gitweb: optionally read config from GITWEB_CONFIG
From: Jeff King @ 2006-08-02 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Configuration will first be taken from variables inside the gitweb.cgi
script, which in turn come from the Makefile. Afterwards, the contents of
GITWEB_CONFIG are read, overriding the builtin defaults.
This should eliminate the need for editing the gitweb script at all. Users
should edit the Makefile and/or add a config file.
Signed-off-by: Jeff King <peff@peff.net>
---
This is on top of next.
This patch seemed to get a favorable response, so I cleaned it up and
actually tested it. The main changes are reordering a few of the setup
statements so that changes introduced in the config file are respected
as suggested by Matthias (and a few by me). It would be good if other
gitweb people could check it over and/or try it with their config to
make sure I didn't miss anything.
Makefile | 2 ++
gitweb/gitweb.perl | 19 ++++++++++++-------
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 2562a2c..170d082 100644
--- a/Makefile
+++ b/Makefile
@@ -127,6 +127,7 @@ GIT_PYTHON_DIR = $(prefix)/share/git-cor
# DESTDIR=
# default configuration for gitweb
+GITWEB_CONFIG = gitweb_config.perl
GITWEB_SITENAME =
GITWEB_PROJECTROOT = /pub/git
GITWEB_LIST =
@@ -629,6 +630,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e 's|@@GIT_VERSION@@|$(GIT_VERSION)|g' \
-e 's|@@GIT_BINDIR@@|$(bindir)|g' \
+ -e 's|@@GITWEB_CONFIG@@|$(GITWEB_CONFIG)|g' \
-e 's|@@GITWEB_SITENAME@@|$(GITWEB_SITENAME)|g' \
-e 's|@@GITWEB_PROJECTROOT@@|$(GITWEB_PROJECTROOT)|g' \
-e 's|@@GITWEB_LIST@@|$(GITWEB_LIST)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1db1414..d5b2de8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -31,14 +31,8 @@ # absolute fs-path which will be prepend
#our $projectroot = "/pub/scm";
our $projectroot = "@@GITWEB_PROJECTROOT@@";
-# version of the core git binary
-our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
-
# location for temporary files needed for diffs
our $git_temp = "/tmp/gitweb";
-if (! -d $git_temp) {
- mkdir($git_temp, 0700) || die_error("Couldn't mkdir $git_temp");
-}
# target of the home link on top of all pages
our $home_link = $my_uri;
@@ -56,7 +50,7 @@ # URI of GIT logo
our $logo = "@@GITWEB_LOGO@@";
# source of projects list
-our $projects_list = "@@GITWEB_LIST@@" || "$projectroot";
+our $projects_list = "@@GITWEB_LIST@@";
# default blob_plain mimetype and default charset for text/plain blob
our $default_blob_plain_mimetype = 'text/plain';
@@ -66,6 +60,17 @@ # file to use for guessing MIME types be
# (relative to the current git repository)
our $mimetypes_file = undef;
+our $GITWEB_CONFIG = "@@GITWEB_CONFIG@@";
+require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
+
+# version of the core git binary
+our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
+
+$projects_list ||= $projectroot;
+if (! -d $git_temp) {
+ mkdir($git_temp, 0700) || die_error("Couldn't mkdir $git_temp");
+}
+
# input validation and dispatch
our $action = $cgi->param('a');
if (defined $action) {
--
1.4.2.rc2.g59706-dirty
^ permalink raw reply related
* Re: What's in git.git
From: carbonated beverage @ 2006-08-02 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1ws0xb9y.fsf@assigned-by-dhcp.cox.net>
Any plans on a fix for:
http://marc.theaimsgroup.com/?l=git&m=115089393505286&w=2
I use gitk a lot, but having to nuke ~/.gitk every time I launch it is a bit
annoying. :-)
Commenting out the line mentioned in the reply lets me resize the window and
see the bottom panel properly -- but I do have to resize it every time so it
doesn't extend past the bottom of the screen.
FYI, if it's not easy to reproduct, I'm running it on Debian/stable systems,
i386 and x86_64, both with backports.org X servers, using tcl/tk 8.4
-- DN
Daniel Nobuto
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Customization
From: Matthias Lederhofer @ 2006-08-02 19:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git, Martin Waitz
In-Reply-To: <7v8xm8xbaa.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> They all try to make customization can be done in one
> place, and the difference is mostly of taste, so I'd just pick
> one from Martin.
I hope it will be possible (see require suggestion from Jeff King) to
specify the file also from the environment because then it is possible
to develop on an uncostumized version of gitweb.perl. Now I noticed
a problem: do not use the @@FOO@@ in double quotes because perl will
spit a lot of warnings like
"Possible unintended interpolation of @GIT_VERSION in string"
Either we should use another delimiter or use single quotes (this is
the way it is done in git-send-email.perl and git-svn.perl). I don't
know how likely it is that characters that are interpreted different
in double quotes are in filenames but I'd prefer single quotes just to
be on the safe site. This disallows using '/etc/foo/$ENV{SITE_NAME}'
as config file but one can just use '/etc/foo/bar' which requires
'/etc/foo/$ENV{SITE_NAME}'.
^ permalink raw reply
* [PATCH] gitweb: use single quotes for values replaced by the Makefile
From: Matthias Lederhofer @ 2006-08-02 20:17 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060802192333.GA30861@coredump.intra.peff.net>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
This patch is on top of the last one.
> Now I noticed a problem: do not use the @@FOO@@ in double quotes
> because perl will spit a lot of warnings like "Possible unintended
> interpolation of @GIT_VERSION in string" Either we should use
> another delimiter or use single quotes (this is the way it is done
> in git-send-email.perl and git-svn.perl). I don't know how likely
> it is that characters that are interpreted different in double
> quotes are in filenames but I'd prefer single quotes just to be on
> the safe site. This disallows using '/etc/foo/$ENV{SITE_NAME}' as
> config file but one can just use '/etc/foo/bar' which requires
> '/etc/foo/$ENV{SITE_NAME}'.
---
gitweb/gitweb.perl | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d5b2de8..f4c0d87 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -18,18 +18,18 @@ use File::Find qw();
binmode STDOUT, ':utf8';
our $cgi = new CGI;
-our $version = "@@GIT_VERSION@@";
+our $version = '@@GIT_VERSION@@';
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
our $rss_link = "";
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
-our $GIT = "@@GIT_BINDIR@@/git";
+our $GIT = '@@GIT_BINDIR@@/git';
# absolute fs-path which will be prepended to the project path
#our $projectroot = "/pub/scm";
-our $projectroot = "@@GITWEB_PROJECTROOT@@";
+our $projectroot = '@@GITWEB_PROJECTROOT@@';
# location for temporary files needed for diffs
our $git_temp = "/tmp/gitweb";
@@ -39,18 +39,18 @@ our $home_link = $my_uri;
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
-our $site_name = "@@GITWEB_SITENAME@@" || $ENV{'SERVER_NAME'} || "Untitled";
+our $site_name = '@@GITWEB_SITENAME@@' || $ENV{'SERVER_NAME'} || "Untitled";
# html text to include at home page
-our $home_text = "@@GITWEB_HOMETEXT@@";
+our $home_text = '@@GITWEB_HOMETEXT@@';
# URI of default stylesheet
-our $stylesheet = "@@GITWEB_CSS@@";
+our $stylesheet = '@@GITWEB_CSS@@';
# URI of GIT logo
-our $logo = "@@GITWEB_LOGO@@";
+our $logo = '@@GITWEB_LOGO@@';
# source of projects list
-our $projects_list = "@@GITWEB_LIST@@";
+our $projects_list = '@@GITWEB_LIST@@';
# default blob_plain mimetype and default charset for text/plain blob
our $default_blob_plain_mimetype = 'text/plain';
@@ -60,7 +60,7 @@ # file to use for guessing MIME types be
# (relative to the current git repository)
our $mimetypes_file = undef;
-our $GITWEB_CONFIG = "@@GITWEB_CONFIG@@";
+our $GITWEB_CONFIG = '@@GITWEB_CONFIG@@';
require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
# version of the core git binary
--
1.4.2.rc2.g4713
^ permalink raw reply related
* Re: kompare won't parse git diffs
From: Jakub Narebski @ 2006-08-02 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0608021207360.4168@g5.osdl.org>
Linus Torvalds wrote:
> On Wed, 2 Aug 2006, Jakub Narebski wrote:
>
>> > Now, if the kompare people can show that every single other patch
>> > generator adds the stupid tab + date format, I guess we could do it too,
>> > but
>> > (a) there is no valid date in general to use, so it's a fundamentally
>> > broken notion and
>>
>> Meaning we don't save timestamp in git ;-) Well, we could use date of the
>> commit which created given file contents (first commit from root, or last
>> from head which contains given version)... but the same contents might be
>> introduced independently in different commits. And different clones of the
>> same repository might have different commit dates...
>
> Exactly, a "date" in _any_ distributed SCM makes no sense what-so-ever.
> What happens across a merge? Which date do you take? Do you follow the
> thing down and basically do a full "annotate" on the file?
>
> The fact is, dates in SCM diffs are insane and stupid. They do not make
> sense in the presense of an SCM, and they only make sense on individual
> _files_ (and quite limited there too, but at least it has _some_ meaning).
What about putting e.g. sha1 (or abbreviated sha1) of blob if file exist
in repository, "(in index)" or "(working area)" in two other cases, instead
of date or file version?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: optionally read config from GITWEB_CONFIG
From: Jakub Narebski @ 2006-08-02 20:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060802192333.GA30861@coredump.intra.peff.net>
Jeff King wrote:
> Configuration will first be taken from variables inside the gitweb.cgi
> script, which in turn come from the Makefile. Afterwards, the contents of
> GITWEB_CONFIG are read, overriding the builtin defaults.
>
> This should eliminate the need for editing the gitweb script at all. Users
> should edit the Makefile and/or add a config file.
Very nice.
> @@ -56,7 +50,7 @@ # URI of GIT logo
> our $logo = "@@GITWEB_LOGO@@";
>
> # source of projects list
> -our $projects_list = "@@GITWEB_LIST@@" || "$projectroot";
> +our $projects_list = "@@GITWEB_LIST@@";
>
> # default blob_plain mimetype and default charset for text/plain blob
> our $default_blob_plain_mimetype = 'text/plain';
But why that change?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: optionally read config from GITWEB_CONFIG
From: Junio C Hamano @ 2006-08-02 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060802192333.GA30861@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Configuration will first be taken from variables inside the gitweb.cgi
> script, which in turn come from the Makefile. Afterwards, the contents of
> GITWEB_CONFIG are read, overriding the builtin defaults.
>
> This should eliminate the need for editing the gitweb script at all. Users
> should edit the Makefile and/or add a config file.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This is on top of next.
>
> This patch seemed to get a favorable response, so I cleaned it up and
> actually tested it. The main changes are reordering a few of the setup
> statements so that changes introduced in the config file are respected
> as suggested by Matthias (and a few by me). It would be good if other
> gitweb people could check it over and/or try it with their config to
> make sure I didn't miss anything.
Looks good -- thanks. Further comments from the list are very
much appreciated.
^ permalink raw reply
* [PATCH] gitweb: require $ENV{'GITWEB_CONFIG'}
From: Matthias Lederhofer @ 2006-08-02 20:29 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060802192333.GA30861@coredump.intra.peff.net>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
With this patch it is possible to use gitweb.perl for developing by
loading the configuration from $GITWEB_CONFIG. This might also be
useful for normal usage of gitweb. Example:
% cat cfg
$GIT = '/usr/bin/git';
$projectroot = '/home/matled/src/git';
$projects_list = '/home/matled/src/git/git/gitweb/list';
% cat run
#!/bin/sh
export GATEWAY_INTERFACE="CGI/1.1"
export HTTP_ACCEPT="*/*"
export REQUEST_METHOD="GET"
export GITWEB_CONFIG='./cfg'
export QUERY_STRING=""$1""
exec ./gitweb.perl
% time ./run p=git/.git > /dev/null
./run p=git/.git > /dev/null 0.47s user 0.58s system 102% cpu 1.025
total
This makes it easy to check for warnings and do performance tests
after changes, you can also pipe this to lynx -dump -force-html
/dev/stdin to get more than just html :)
This also documents the original patch adding require $GITWEB_CONFIG.
---
gitweb/README | 5 +++++
gitweb/gitweb.perl | 4 ++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index b91d42a..dc4b850 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -23,6 +23,11 @@ You can specify the following configurat
Points to the location where you put gitweb.css on your web server.
* GITWEB_LOGO
Points to the location where you put git-logo.png on your web server.
+ * GITWEB_CONFIG
+ This file will be loaded using 'require'. If the environment
+ $GITWEB_CONFIG is set when gitweb.cgi is executed the file in the
+ environment variable will be loaded additionally (after) the file
+ specified when gitweb.cgi was created.
Originally written by:
Kay Sievers <kay.sievers@vrfy.org>
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f4c0d87..efcc926 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -63,6 +63,10 @@ our $mimetypes_file = undef;
our $GITWEB_CONFIG = '@@GITWEB_CONFIG@@';
require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
+if (defined($ENV{'GITWEB_CONFIG'}) && -e $ENV{'GITWEB_CONFIG'}) {
+ require $ENV{'GITWEB_CONFIG'};
+}
+
# version of the core git binary
our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
--
1.4.2.rc2.g4713
^ permalink raw reply related
* Re: [PATCH] gitweb.cgi: Customization
From: Luben Tuikov @ 2006-08-02 20:30 UTC (permalink / raw)
To: Jon Loeliger, Junio C Hamano; +Cc: Git List, Martin Waitz, Matthias Lederhofer
In-Reply-To: <1154535801.19994.15.camel@cashmere.sps.mot.com>
--- Jon Loeliger <jdl@freescale.com> wrote:
> On Tue, 2006-08-01 at 18:54, Junio C Hamano wrote:
>
> > In any case, I think tweaking gitweb.cgi from Makefile like
> > Martin Waitz did is as easy and clean for people who want to
> > customize; it should just be the matter of defining the
> > necessary params in config.mak.
>
> I disagree. I run multiple virtual web servers on one
> physical machine. Several of them run different gitweb
> instances, each with different configurations.
>
> With this "params in config.mk" approach, I have to
> run it multiple times, once for each web server I run.
That's exactly my sentiments.
> I _really_ would prefer an "include from ." feature
> where I can place the specific gitweb_config.pm parts
> in the same directory where gitweb.{pl,cgi} is installed.
Yes, this approach is simple and straightforward enough.
When upgrading, one only needs to do a "cp".
> We really need to separate out these config values
> from the gitweb.{pl,cgi} script itself. We _need_ to
> be able to update the gitweb script independently,
> and easily.
That's exactly where I was going with this patch.
I don't want to have to:
- configure httpd, or
- configure the environment of user "apache", or
- have a separate forked off branch in order to "configure"
gitweb at compile time for each gitweb instance I'm running,
- etc, etc, etc.
Configuration, especially of user space programs should be
completely dynamic. Compilation for user space programs should
be a separate process from configuration.
> > I do not think there is much difference between any of the
> > customization proposed so far (yours, Martin's and the one from
> > Matthias Lederhofer) from functionality and ease-of-use point of
> > view. They all try to make customization can be done in one
> > place, and the difference is mostly of taste, so I'd just pick
> > one from Martin.
>
> Let's just make sure it is a separate config file, please.
I thing your and mine deployment are pretty similar, thus warranting
a more flexible approach, withouth having to recompile or reconfigure
completely unrelated programs and users.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: optionally read config from GITWEB_CONFIG
From: Matthias Lederhofer @ 2006-08-02 20:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ear1fp$j9p$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Jeff King wrote:
> > @@ -56,7 +50,7 @@ # URI of GIT logo
> > our $logo = "@@GITWEB_LOGO@@";
> >
> > # source of projects list
> > -our $projects_list = "@@GITWEB_LIST@@" || "$projectroot";
> > +our $projects_list = "@@GITWEB_LIST@@";
> >
> > # default blob_plain mimetype and default charset for text/plain blob
> > our $default_blob_plain_mimetype = 'text/plain';
>
> But why that change?
Earlier this was undef if the user did not change it. Now this is
always a string so the second one will probably never come into play
except the user chooses to set the string to undef again.
^ permalink raw reply
* Re: [PATCH] gitweb: optionally read config from GITWEB_CONFIG
From: Jakub Narebski @ 2006-08-02 20:36 UTC (permalink / raw)
To: git
In-Reply-To: <E1G8NNl-0006ez-6J@moooo.ath.cx>
Matthias Lederhofer wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Jeff King wrote:
>> > @@ -56,7 +50,7 @@ # URI of GIT logo
>> > our $logo = "@@GITWEB_LOGO@@";
>> >
>> > # source of projects list
>> > -our $projects_list = "@@GITWEB_LIST@@" || "$projectroot";
>> > +our $projects_list = "@@GITWEB_LIST@@";
>> >
>> > # default blob_plain mimetype and default charset for text/plain blob
>> > our $default_blob_plain_mimetype = 'text/plain';
>>
>> But why that change?
> Earlier this was undef if the user did not change it. Now this is
> always a string so the second one will probably never come into play
> except the user chooses to set the string to undef again.
Empty string is also false in Perl. Try
perl -e 'my $var = "" || "other"; print "var = $var\n";'
I'd rather use $projectroot for $projects_list, preferably without needing
to set $projects_list.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: optionally read config from GITWEB_CONFIG
From: Jeff King @ 2006-08-02 20:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ear1fp$j9p$2@sea.gmane.org>
On Wed, Aug 02, 2006 at 10:21:43PM +0200, Jakub Narebski wrote:
> > @@ -56,7 +50,7 @@ # URI of GIT logo
> > our $logo = "@@GITWEB_LOGO@@";
> >
> > # source of projects list
> > -our $projects_list = "@@GITWEB_LIST@@" || "$projectroot";
> > +our $projects_list = "@@GITWEB_LIST@@";
> >
> > # default blob_plain mimetype and default charset for text/plain blob
> > our $default_blob_plain_mimetype = 'text/plain';
>
> But why that change?
Because the previous order was:
1. set projectroot to build-time default
2. set projects_list to build-time default or $projectroot
3. read variables, including $projectroot, from config file
If you kept $projects_list empty but set $projectroot in your config,
the value of projects_list would be the build-time $projectroot, not the
config-time. If you look further in the patch, you will see that we set
up projects_list later.
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb: require $ENV{'GITWEB_CONFIG'}
From: Jeff King @ 2006-08-02 20:50 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Junio C Hamano, git
In-Reply-To: <E1G8NLU-0006TL-J7@moooo.ath.cx>
On Wed, Aug 02, 2006 at 10:29:36PM +0200, Matthias Lederhofer wrote:
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -63,6 +63,10 @@ our $mimetypes_file = undef;
> our $GITWEB_CONFIG = '@@GITWEB_CONFIG@@';
> require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
>
> +if (defined($ENV{'GITWEB_CONFIG'}) && -e $ENV{'GITWEB_CONFIG'}) {
> + require $ENV{'GITWEB_CONFIG'};
> +}
> +
> # version of the core git binary
> our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
I think this patch is a good idea, but it seems confusing to have two
different config files. Maybe the environment should trump the built-in
default:
our $GITWEB_CONFIG = $ENV{GITWEB_CONFIG} || '@@GITWEB_CONFIG@@';
Which actually might be a reasonable thing for all of the config
directives (so people can use a config file, apache environment munging,
or the built-in defaults). I would think the sanest order would be
environment, then config file, then built-ins (which is what all the
rest of the git programs do).
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb: use single quotes for values replaced by the Makefile
From: Junio C Hamano @ 2006-08-02 20:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <E1G8N9c-0004GK-Gz@moooo.ath.cx>
I understand that (1) "@@FOO@@" is problematic, (2) being able
to run gitweb/gitweb.perl while coming up with improvements is
nice, but (3) not being able to say "/etc/foo/$ENV{SITE_NAME}"
is quite a drawback on the deployment side.
So why don't we use something other than @@, perhaps "++FOO++"?
I'm inclined to take these two patches:
gitweb: optionally read config from GITWEB_CONFIG (Jeff King)
gitweb: require $ENV{'GITWEB_CONFIG'} (Matthias Lederhofer)
so on top of them something like this?
-- >8 --
[PATCH] gitweb: do not use @@FOO@@ for replaced tokens
This makes it easier to run gitweb/gitweb.perl without token substitution.
Using @@ makes Perl emit "unintended interpolation" warnings.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 18 +++++++++---------
gitweb/gitweb.perl | 18 +++++++++---------
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/Makefile b/Makefile
index a2b4aca..3816ef7 100644
--- a/Makefile
+++ b/Makefile
@@ -584,15 +584,15 @@ git-status: git-commit
gitweb/gitweb.cgi: gitweb/gitweb.perl
rm -f $@ $@+
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
- -e 's|@@GIT_VERSION@@|$(GIT_VERSION)|g' \
- -e 's|@@GIT_BINDIR@@|$(bindir)|g' \
- -e 's|@@GITWEB_CONFIG@@|$(GITWEB_CONFIG)|g' \
- -e 's|@@GITWEB_SITENAME@@|$(GITWEB_SITENAME)|g' \
- -e 's|@@GITWEB_PROJECTROOT@@|$(GITWEB_PROJECTROOT)|g' \
- -e 's|@@GITWEB_LIST@@|$(GITWEB_LIST)|g' \
- -e 's|@@GITWEB_HOMETEXT@@|$(GITWEB_HOMETEXT)|g' \
- -e 's|@@GITWEB_CSS@@|$(GITWEB_CSS)|g' \
- -e 's|@@GITWEB_LOGO@@|$(GITWEB_LOGO)|g' \
+ -e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
+ -e 's|++GIT_BINDIR++|$(bindir)|g' \
+ -e 's|++GITWEB_CONFIG++|$(GITWEB_CONFIG)|g' \
+ -e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
+ -e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
+ -e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
+ -e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
+ -e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
+ -e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
$< >$@+
chmod +x $@+
mv $@+ $@
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c7f13e7..3cd2b89 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -18,18 +18,18 @@ use File::Find qw();
binmode STDOUT, ':utf8';
our $cgi = new CGI;
-our $version = "@@GIT_VERSION@@";
+our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
our $rss_link = "";
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
-our $GIT = "@@GIT_BINDIR@@/git";
+our $GIT = "++GIT_BINDIR++/git";
# absolute fs-path which will be prepended to the project path
#our $projectroot = "/pub/scm";
-our $projectroot = "@@GITWEB_PROJECTROOT@@";
+our $projectroot = "++GITWEB_PROJECTROOT++";
# location for temporary files needed for diffs
our $git_temp = "/tmp/gitweb";
@@ -39,18 +39,18 @@ our $home_link = $my_uri;
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
-our $site_name = "@@GITWEB_SITENAME@@" || $ENV{'SERVER_NAME'} || "Untitled";
+our $site_name = "++GITWEB_SITENAME++" || $ENV{'SERVER_NAME'} || "Untitled";
# html text to include at home page
-our $home_text = "@@GITWEB_HOMETEXT@@";
+our $home_text = "++GITWEB_HOMETEXT++";
# URI of default stylesheet
-our $stylesheet = "@@GITWEB_CSS@@";
+our $stylesheet = "++GITWEB_CSS++";
# URI of GIT logo
-our $logo = "@@GITWEB_LOGO@@";
+our $logo = "++GITWEB_LOGO++";
# source of projects list
-our $projects_list = "@@GITWEB_LIST@@";
+our $projects_list = "++GITWEB_LIST++";
# default blob_plain mimetype and default charset for text/plain blob
our $default_blob_plain_mimetype = 'text/plain';
@@ -60,7 +60,7 @@ # file to use for guessing MIME types be
# (relative to the current git repository)
our $mimetypes_file = undef;
-our $GITWEB_CONFIG = "@@GITWEB_CONFIG@@";
+our $GITWEB_CONFIG = "++GITWEB_CONFIG++";
require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
if (defined($ENV{'GITWEB_CONFIG'}) && -e $ENV{'GITWEB_CONFIG'}) {
--
1.4.2.rc2.g767b2
^ permalink raw reply related
* Re: [PATCH] gitweb: optionally read config from GITWEB_CONFIG
From: Luben Tuikov @ 2006-08-02 20:51 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git
In-Reply-To: <20060802192333.GA30861@coredump.intra.peff.net>
--- Jeff King <peff@peff.net> wrote:
> Configuration will first be taken from variables inside the gitweb.cgi
> script, which in turn come from the Makefile. Afterwards, the contents of
> GITWEB_CONFIG are read, overriding the builtin defaults.
>
> This should eliminate the need for editing the gitweb script at all. Users
> should edit the Makefile and/or add a config file.
I don't think users should even edit the Makefile. Makefiles are normally
edited when the _build_ environment differs, not when the deployment
environment differs.
For example, some of us use the same gitweb.cgi/perl/pl (or whatever the
next completely unnecessary renaming would be) for deployment on several
"sites" and repositories.
I cannot imagine anyone who actually _uses_ and maintains gitweb.cgi/perl/pl
to edit the Makefile for their deployment, thus having to have a forked off
branch(es) for each of their deployments (which the only diff editing the Makefile).
Luben
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This is on top of next.
>
> This patch seemed to get a favorable response, so I cleaned it up and
> actually tested it. The main changes are reordering a few of the setup
> statements so that changes introduced in the config file are respected
> as suggested by Matthias (and a few by me). It would be good if other
> gitweb people could check it over and/or try it with their config to
> make sure I didn't miss anything.
>
> Makefile | 2 ++
> gitweb/gitweb.perl | 19 ++++++++++++-------
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 2562a2c..170d082 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -127,6 +127,7 @@ GIT_PYTHON_DIR = $(prefix)/share/git-cor
> # DESTDIR=
>
> # default configuration for gitweb
> +GITWEB_CONFIG = gitweb_config.perl
> GITWEB_SITENAME =
> GITWEB_PROJECTROOT = /pub/git
> GITWEB_LIST =
> @@ -629,6 +630,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
> sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
> -e 's|@@GIT_VERSION@@|$(GIT_VERSION)|g' \
> -e 's|@@GIT_BINDIR@@|$(bindir)|g' \
> + -e 's|@@GITWEB_CONFIG@@|$(GITWEB_CONFIG)|g' \
> -e 's|@@GITWEB_SITENAME@@|$(GITWEB_SITENAME)|g' \
> -e 's|@@GITWEB_PROJECTROOT@@|$(GITWEB_PROJECTROOT)|g' \
> -e 's|@@GITWEB_LIST@@|$(GITWEB_LIST)|g' \
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 1db1414..d5b2de8 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -31,14 +31,8 @@ # absolute fs-path which will be prepend
> #our $projectroot = "/pub/scm";
> our $projectroot = "@@GITWEB_PROJECTROOT@@";
>
> -# version of the core git binary
> -our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> -
> # location for temporary files needed for diffs
> our $git_temp = "/tmp/gitweb";
> -if (! -d $git_temp) {
> - mkdir($git_temp, 0700) || die_error("Couldn't mkdir $git_temp");
> -}
>
> # target of the home link on top of all pages
> our $home_link = $my_uri;
> @@ -56,7 +50,7 @@ # URI of GIT logo
> our $logo = "@@GITWEB_LOGO@@";
>
> # source of projects list
> -our $projects_list = "@@GITWEB_LIST@@" || "$projectroot";
> +our $projects_list = "@@GITWEB_LIST@@";
>
> # default blob_plain mimetype and default charset for text/plain blob
> our $default_blob_plain_mimetype = 'text/plain';
> @@ -66,6 +60,17 @@ # file to use for guessing MIME types be
> # (relative to the current git repository)
> our $mimetypes_file = undef;
>
> +our $GITWEB_CONFIG = "@@GITWEB_CONFIG@@";
> +require $GITWEB_CONFIG if -e $GITWEB_CONFIG;
> +
> +# version of the core git binary
> +our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> +
> +$projects_list ||= $projectroot;
> +if (! -d $git_temp) {
> + mkdir($git_temp, 0700) || die_error("Couldn't mkdir $git_temp");
> +}
> +
> # input validation and dispatch
> our $action = $cgi->param('a');
> if (defined $action) {
> --
> 1.4.2.rc2.g59706-dirty
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: kompare won't parse git diffs
From: Linus Torvalds @ 2006-08-02 20:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ear19d$j9p$1@sea.gmane.org>
On Wed, 2 Aug 2006, Jakub Narebski wrote:
>
> What about putting e.g. sha1 (or abbreviated sha1) of blob if file exist
> in repository, "(in index)" or "(working area)" in two other cases, instead
> of date or file version?
Quite frankly, it will just break the current git header standard, and
make diffs look uglier.
Just get kompare fixed instead. If you want to use it with git, you would
really want it to know about all the other git diff extensions too anyway,
and right now it's _buggy_ for requiring a tab where none needs to be.
If "patch" doesn't want the tab, then dammit, neither should kompare.
Linus
^ 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