* [PATCH] Documentation: Added [verse] to SYNOPSIS where necessary
From: Matthias Kestenholz @ 2007-05-18 13:39 UTC (permalink / raw)
To: junkio; +Cc: git, Matthias Kestenholz
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/git-archive.txt | 1 +
Documentation/git-bundle.txt | 1 +
Documentation/git-fmt-merge-msg.txt | 1 +
Documentation/git-name-rev.txt | 1 +
Documentation/git-rebase.txt | 2 +-
5 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index d3ca9a9..721e035 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -8,6 +8,7 @@ git-archive - Creates an archive of files from a named tree
SYNOPSIS
--------
+[verse]
'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--remote=<repo>] <tree-ish> [path...]
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 92e7a68..5051e2b 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -8,6 +8,7 @@ git-bundle - Move objects and refs by archive
SYNOPSIS
--------
+[verse]
'git-bundle' create <file> [git-rev-list args]
'git-bundle' verify <file>
'git-bundle' list-heads <file> [refname...]
diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt
index e560b30..4913c25 100644
--- a/Documentation/git-fmt-merge-msg.txt
+++ b/Documentation/git-fmt-merge-msg.txt
@@ -8,6 +8,7 @@ git-fmt-merge-msg - Produce a merge commit message
SYNOPSIS
--------
+[verse]
git-fmt-merge-msg [--summary | --no-summary] <$GIT_DIR/FETCH_HEAD
git-fmt-merge-msg [--summary | --no-summray] -F <file>
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 5b5c4c8..d6c8bf8 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -8,6 +8,7 @@ git-name-rev - Find symbolic names for given revs
SYNOPSIS
--------
+[verse]
'git-name-rev' [--tags] [--refs=<pattern>]
( --all | --stdin | <committish>... )
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2f417a8..753b275 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -7,8 +7,8 @@ git-rebase - Forward-port local commits to the updated upstream head
SYNOPSIS
--------
+[verse]
'git-rebase' [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>]
-
'git-rebase' --continue | --skip | --abort
DESCRIPTION
--
1.5.2.rc3.50.gfdcb7
^ permalink raw reply related
* [PATCH] Documentation: Reformatted SYNOPSIS for several commands
From: Matthias Kestenholz @ 2007-05-18 13:39 UTC (permalink / raw)
To: junkio; +Cc: git, Matthias Kestenholz
In-Reply-To: <11794955741820-git-send-email-matthias@spinlock.ch>
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/git-for-each-ref.txt | 5 ++++-
Documentation/git-index-pack.txt | 4 +++-
Documentation/git-instaweb.txt | 5 +++--
Documentation/git-local-fetch.txt | 4 +++-
Documentation/git-p4import.txt | 6 +++---
Documentation/git-push.txt | 4 +++-
6 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index f49b0d9..6df8e85 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -7,7 +7,10 @@ git-for-each-ref - Output information on each ref
SYNOPSIS
--------
-'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python|--tcl] [--sort=<key>]\* [--format=<format>] [<pattern>]
+[verse]
+'git-for-each-ref' [--count=<count>]\*
+ [--shell|--perl|--python|--tcl]
+ [--sort=<key>]\* [--format=<format>] [<pattern>]
DESCRIPTION
-----------
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index b7a49b9..2269269 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -8,8 +8,10 @@ git-index-pack - Build pack index file for an existing packed archive
SYNOPSIS
--------
+[verse]
'git-index-pack' [-v] [-o <index-file>] <pack-file>
-'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>] [<pack-file>]
+'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
+ [<pack-file>]
DESCRIPTION
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
index 52a6aa6..9df0ab2 100644
--- a/Documentation/git-instaweb.txt
+++ b/Documentation/git-instaweb.txt
@@ -7,8 +7,9 @@ git-instaweb - Instantly browse your working repository in gitweb
SYNOPSIS
--------
-'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
-
+[verse]
+'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
+ [--browser=<browser>]
'git-instaweb' [--start] [--stop] [--restart]
DESCRIPTION
diff --git a/Documentation/git-local-fetch.txt b/Documentation/git-local-fetch.txt
index dd9e238..51389ef 100644
--- a/Documentation/git-local-fetch.txt
+++ b/Documentation/git-local-fetch.txt
@@ -8,7 +8,9 @@ git-local-fetch - Duplicate another git repository on a local system
SYNOPSIS
--------
-'git-local-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path
+[verse]
+'git-local-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n]
+ commit-id path
DESCRIPTION
-----------
diff --git a/Documentation/git-p4import.txt b/Documentation/git-p4import.txt
index 6edb9f1..714abbe 100644
--- a/Documentation/git-p4import.txt
+++ b/Documentation/git-p4import.txt
@@ -8,10 +8,10 @@ git-p4import - Import a Perforce repository into git
SYNOPSIS
--------
-`git-p4import` [-q|-v] [--notags] [--authors <file>] [-t <timezone>] <//p4repo/path> <branch>
-
+[verse]
+`git-p4import` [-q|-v] [--notags] [--authors <file>] [-t <timezone>]
+ <//p4repo/path> <branch>
`git-p4import` --stitch <//p4repo/path>
-
`git-p4import`
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index f8cc2b5..e9ad106 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -8,7 +8,9 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
-'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
+[verse]
+'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>]
+ [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
DESCRIPTION
-----------
--
1.5.2.rc3.50.gfdcb7
^ permalink raw reply related
* Re: git-rebase (1.5.0.6) errors
From: Ilpo Järvinen @ 2007-05-18 14:02 UTC (permalink / raw)
To: David Kastrup; +Cc: Paolo Teti, git
In-Reply-To: <34a7ae040705180331x1a86782fh3b2c6a87db32030e@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 761 bytes --]
David Kastrup <dak@gnu.org> wrote:
> Only if size_t is a larger type than int (could be on x86-64 and alpha
> architectures). Other than that, this comparison would work. Which
> does not mean that this does not warrant fixing, but it is not
> necessarily the cause of this problem.
...sizeof(size_t) == sizeof(int) should hold...
Anyway, if this has any relevance: I'm using non-utf system, and (as you
see) my surname has ä... The system was recently upgraded to git 1.5+
which started to complain also about a missing i18n.commitencoding,
figured out that when I set it to utf8 (empty => defaults to it) and have
signed-off line (with native non-utf ä), I get that error...
...and please, do not drop me from cc since I'm not subscribed...
--
i.
^ permalink raw reply
* GIT_DIR used to work with git-1.4.4.4
From: Christian MICHON @ 2007-05-18 14:24 UTC (permalink / raw)
To: git
sorry if I created too much (user) noise around this issue, but
this is mostly why as a user I refrained using git-1.5.x
I sometimes have a scm work flow where I'd like to have my
GIT_DIR sitting on another file system, so therefore not in
the current working directory.
I used to be able to do this in git-1.4.4.4:
(it's a rather useless example, I know)
mkdir /home/xian/vault
export GIT_DIR=/home/xian/vault
mkdir /tmp/xianwork
cd /tmp/xianwork
touch a b
git init-db
git add .
This was truly working, and now using git-1.5.1.4, it's not.
Instead I get: "fatal: add must be run in a work tree"
from the source code, I understand what to change if I
want to get the old behavior.
My questions are:
- is this new behavior truly needed ?
- is there another way to do this using newer work flow ?
( I know already about the symbolic .git link trick )
Thanks in advance for any useful tips.
--
Christian
^ permalink raw reply
* Re: git-rebase (1.5.0.6) errors
From: Paolo Teti @ 2007-05-18 14:39 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0705181640270.14736@kivilampi-30.cs.helsinki.fi>
2007/5/18, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>:
> ...sizeof(size_t) == sizeof(int) should hold...
what I have reported is not necessarily the cause of your error. Yes
BUT size_t is UNSIGNED and ssize_t is SIGNED.
The problem is that We store a signed return value into a unsigned variable.
So the check against -1 has no sense.
and please note that also sizeof(int) == sizeof(unsigned int), but -1
is a signed int !!
I repeat: this is not necessarily the cause of your error.
^ permalink raw reply
* Re: git-rebase (1.5.0.6) errors
From: Paolo Teti @ 2007-05-18 15:08 UTC (permalink / raw)
To: David Kastrup; +Cc: Ilpo Järvinen, git
In-Reply-To: <864pmamb6b.fsf@lola.quinscape.zz>
2007/5/18, David Kastrup <dak@gnu.org>:
> "Paolo Teti" <paolo.teti@gmail.com> writes:
>
> > 2007/5/18, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>:
> >
> >> ...sizeof(size_t) == sizeof(int) should hold...
> >
> > what I have reported is not necessarily the cause of your error. Yes
> >
> > BUT size_t is UNSIGNED and ssize_t is SIGNED.
> >
> > The problem is that We store a signed return value into a unsigned variable.
> > So the check against -1 has no sense.
>
> When comparing signed with unsigned types, the signed values are first
> converted to unsigned, then possibly zero-extended.
>
> So
>
> (unsigned)-1 == (int)-1
>
> but
>
> (unsigned long)-1 == (long)-1
>
> only when sizeof(long)==size(int)
>
> > and please note that also sizeof(int) == sizeof(unsigned int), but
> > -1 is a signed int !!
>
> So?
>
Stupid me.. OK is == -1 and not < 0..
Probably today I'm drunk without drink ..
Enjoy
^ permalink raw reply
* [PATCH] gitweb: Incremental blame
From: Petr Baudis @ 2007-05-18 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Fredrik Kuivinen
This is tweaked up version of Fredrik Kuivinen <frekui@gmail.com>'s proof
of concept patch to add support for incrementally displaying line data in
the blame view using some javascript gadgetry.
The original patch has been lightly tested in a couple of browsers
(Firefox, Mozilla, Konqueror, Galeon, Opera and IE6). The new patch has
been tested in Firefox and Epiphany (and works fine in Epiphany 2.14.3,
contrary to what the original patch claimed).
Compared to the original patch, this one works with pathinfo-ish URLs as
well, and should play well with non-javascript browsers as well (the HTML
points to the blame action, while javascript code rewrites the links to use
the blame_incremental action; it is somewhat hackish but I couldn't think
of a better solution).
As usual, you can see it in action at repo.or.cz. blame view now feels a
lot more friendly.
Cc: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Makefile | 6 +-
git-instaweb.sh | 7 ++
gitweb/blame.js | 193 ++++++++++++++++++++++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 140 +++++++++++++++++++++++++++++++++++---
4 files changed, 335 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index ed12577..46a9fcb 100644
--- a/Makefile
+++ b/Makefile
@@ -168,6 +168,7 @@ GITWEB_HOMETEXT = indextext.html
GITWEB_CSS = gitweb.css
GITWEB_LOGO = git-logo.png
GITWEB_FAVICON = git-favicon.png
+GITWEB_BLAMEJS = blame.js
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
@@ -815,13 +816,14 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
-e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
+ -e 's|++GITWEB_BLAMEJS++|$(GITWEB_BLAMEJS)|g' \
-e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
-e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
$< >$@+ && \
chmod +x $@+ && \
mv $@+ $@
-git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
+git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css gitweb/blame.js
$(QUIET_GEN)rm -f $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
@@ -830,6 +832,8 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
+ -e '/@@GITWEB_BLAMEJS@@/r gitweb/blame.js' \
+ -e '/@@GITWEB_BLAMEJS@@/d' \
$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/git-instaweb.sh b/git-instaweb.sh
index cbc7418..dddbb6b 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -233,8 +233,15 @@ gitweb_css () {
EOFGITWEB
}
+gitweb_blamejs () {
+ cat > "$1" <<\EOFGITWEB
+@@GITWEB_BLAMEJS@@
+EOFGITWEB
+}
+
gitweb_cgi $GIT_DIR/gitweb/gitweb.cgi
gitweb_css $GIT_DIR/gitweb/gitweb.css
+gitweb_blamejs $GIT_DIR/gitweb/blame.js
case "$httpd" in
*lighttpd*)
diff --git a/gitweb/blame.js b/gitweb/blame.js
new file mode 100644
index 0000000..88b6499
--- /dev/null
+++ b/gitweb/blame.js
@@ -0,0 +1,193 @@
+// Copyright (C) 2007, Fredrik Kuivinen <frekui@gmail.com>
+
+var DEBUG = 0;
+function debug(str)
+{
+ if (DEBUG)
+ alert(str);
+}
+
+function createRequestObject() {
+ var ro;
+ if (window.XMLHttpRequest) {
+ ro = new XMLHttpRequest();
+ } else {
+ ro = new ActiveXObject("Microsoft.XMLHTTP");
+ }
+ return ro;
+}
+
+var http;
+var baseUrl;
+
+// 'commits' is an associative map. It maps SHA1s to Commit objects.
+var commits = new Object();
+
+function Commit(sha1)
+{
+ this.sha1 = sha1;
+}
+
+function zeroPad(n)
+{
+ if (n < 10)
+ return '0' + n;
+ else
+ return n.toString();
+}
+
+function handleLine(commit)
+{
+ /* This is the structure of the HTML fragment we are working
+ with:
+
+ <tr id="l123" class="light2">
+ <td class="sha1" title="">
+ <a href=""></a>
+ </td>
+ <td class="linenr">
+ <a class="linenr" href="">123</a>
+ </td>
+ <td class="pre"># times (my ext3 doesn't).</td>
+ </tr>
+ */
+
+ var resline = commit.resline;
+ for (var i = 0; i < commit.numlines; i++) {
+ var tr = document.getElementById('l'+resline);
+ if (!tr) {
+ debug('tr is null! resline: ' + resline);
+ break;
+ }
+
+ var date = new Date();
+ date.setTime(commit.authorTime*1000);
+ var dateStr =
+ date.getUTCFullYear() + '-' +
+ zeroPad(date.getUTCMonth()+1) + '-' +
+ zeroPad(date.getUTCDate());
+ var timeStr =
+ zeroPad(date.getUTCHours()) + ':' +
+ zeroPad(date.getUTCMinutes()) + ':' +
+ zeroPad(date.getUTCSeconds());
+ tr.firstChild.title = commit.author + ', ' + dateStr + ' ' + timeStr;
+ var shaAnchor = tr.firstChild.firstChild;
+ if (i == 0) {
+ shaAnchor.href = baseUrl + ';a=commit;h=' + commit.sha1;
+ shaAnchor.innerHTML = commit.sha1.substr(0, 8);
+ } else {
+ shaAnchor.innerHTML = '';
+ }
+
+ var lineAnchor = tr.firstChild.nextSibling.firstChild;
+ lineAnchor.href = baseUrl + ';a=blame;hb=' + commit.sha1 +
+ ';f=' + commit.filename + '#l' + commit.srcline;
+ resline++;
+ }
+}
+
+function fixColors()
+{
+ var colorClasses = ['light2', 'dark2'];
+ var linenum = 1;
+ var tr;
+ var colorClass = 0;
+
+ while((tr = document.getElementById('l'+linenum))) {
+ if(tr.firstChild.firstChild.innerHTML != '') {
+ colorClass = (colorClass + 1) % 2;
+ }
+ tr.setAttribute('class', colorClasses[colorClass]);
+ // Internet Explorer needs this
+ tr.setAttribute('className', colorClasses[colorClass]);
+ linenum++;
+ }
+}
+
+var prevDataLength = -1;
+var nextLine = 0;
+var inProgress = false;
+
+var sha1Re = new RegExp('([0-9a-f]{40}) ([0-9]+) ([0-9]+) ([0-9]+)');
+var infoRe = new RegExp('([a-z-]+) ?(.*)');
+var curCommit = new Commit();
+
+function handleResponse() {
+ debug('handleResp ready: ' + http.readyState +
+ ' respText null?: ' + (http.responseText === null) +
+ ' progress: ' + inProgress);
+
+ if (http.readyState != 4 && http.readyState != 3)
+ return;
+
+ // In konqueror http.responseText is sometimes null here...
+ if (http.responseText === null)
+ return;
+
+ if (inProgress)
+ return;
+ else
+ inProgress = true;
+
+ while (prevDataLength != http.responseText.length) {
+ if (http.readyState == 4 &&
+ prevDataLength == http.responseText.length) {
+ break;
+ }
+
+ prevDataLength = http.responseText.length;
+ var response = http.responseText.substring(nextLine);
+ var lines = response.split('\n');
+ nextLine = nextLine + response.lastIndexOf('\n') + 1;
+ if (response[response.length-1] != '\n') {
+ lines.pop();
+ }
+
+ for (var i = 0; i < lines.length; i++) {
+ var match = sha1Re.exec(lines[i]);
+ if (match) {
+ var sha1 = match[1];
+ var srcline = parseInt(match[2]);
+ var resline = parseInt(match[3]);
+ var numlines = parseInt(match[4]);
+ var c = commits[sha1];
+ if (!c) {
+ c = new Commit(sha1);
+ commits[sha1] = c;
+ }
+
+ c.srcline = srcline;
+ c.resline = resline;
+ c.numlines = numlines;
+ curCommit = c;
+ } else if ((match = infoRe.exec(lines[i]))) {
+ var info = match[1];
+ var data = match[2];
+ if (info == 'filename') {
+ curCommit.filename = data;
+ handleLine(curCommit);
+ } else if (info == 'author') {
+ curCommit.author = data;
+ } else if (info == 'author-time') {
+ curCommit.authorTime = parseInt(data);
+ }
+ } else if (lines[i] != '') {
+ debug('malformed line: ' + lines[i]);
+ }
+ }
+ }
+
+ if (http.readyState == 4 && prevDataLength == http.responseText.length)
+ fixColors();
+
+ inProgress = false;
+}
+
+function startBlame(blamedataUrl, bUrl)
+{
+ baseUrl = bUrl;
+ http = createRequestObject();
+ http.open('get', blamedataUrl);
+ http.onreadystatechange = handleResponse;
+ http.send(null);
+}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 981fe41..cc671b1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -61,6 +61,8 @@ our $stylesheet = undef;
our $logo = "++GITWEB_LOGO++";
# URI of GIT favicon, assumed to be image/png type
our $favicon = "++GITWEB_FAVICON++";
+# URI of blame.js
+our $blamejs = "++GITWEB_BLAMEJS++";
# URI and label (title) of GIT logo link
#our $logo_url = "http://www.kernel.org/pub/software/scm/git/docs/";
@@ -472,6 +474,8 @@ $git_dir = "$projectroot/$project" if $project;
# dispatch
my %actions = (
"blame" => \&git_blame2,
+ "blame_incremental" => \&git_blame_incremental,
+ "blame_data" => \&git_blame_data,
"blobdiff" => \&git_blobdiff,
"blobdiff_plain" => \&git_blobdiff_plain,
"blob" => \&git_blob,
@@ -570,7 +574,7 @@ sub href(%) {
push @result, $symbol . "=" . esc_param($params{$name});
}
}
- $href .= "?" . join(';', @result) if scalar @result;
+ $href .= "?" . join(';', @result) if $params{-partial_query} or scalar @result;
return $href;
}
@@ -1937,6 +1941,16 @@ sub git_header_html {
<meta name="generator" content="gitweb/$version git/$git_version$mod_perl_version"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
+<script type="text/javascript">/* <![CDATA[ */
+function fixBlameLinks() {
+ var allLinks = document.getElementsByTagName("a");
+ for (var i = 0; i < allLinks.length; i++) {
+ var link = allLinks.item(i);
+ if (link.className == 'blamelink')
+ link.href = link.href.replace("a=blame", "a=blame_incremental");
+ }
+}
+/* ]]> */</script>
EOF
# print out each stylesheet that exist
if (defined $stylesheet) {
@@ -1968,7 +1982,7 @@ EOF
}
print "</head>\n" .
- "<body>\n";
+ "<body onload=\"fixBlameLinks();\">\n";
if (-f $site_header) {
open (my $fd, $site_header);
@@ -2358,7 +2372,7 @@ sub git_print_tree_entry {
if ($have_blame) {
print " | " .
$cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
+ file_name=>"$basedir$t->{'name'}", %base_key), -class => "blamelink"},
"blame");
}
if (defined $hash_base) {
@@ -2608,7 +2622,7 @@ sub git_difftree_body {
"blob") . " | ";
if ($have_blame) {
print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
- file_name=>$diff->{'file'})},
+ file_name=>$diff->{'file'}), -class => "blamelink"},
"blame") . " | ";
}
print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
@@ -2658,7 +2672,7 @@ sub git_difftree_body {
"blob") . " | ";
if ($have_blame) {
print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
- file_name=>$diff->{'file'})},
+ file_name=>$diff->{'file'}), -class => "blamelink"},
"blame") . " | ";
}
print $cgi->a({-href => href(action=>"history", hash_base=>$hash,
@@ -2703,7 +2717,7 @@ sub git_difftree_body {
"blob") . " | ";
if ($have_blame) {
print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
- file_name=>$diff->{'to_file'})},
+ file_name=>$diff->{'to_file'}), -class => "blamelink"},
"blame") . " | ";
}
print $cgi->a({-href => href(action=>"history", hash_base=>$hash,
@@ -3577,6 +3591,112 @@ sub git_tag {
git_footer_html();
}
+sub git_blame_data {
+ my $fd;
+ my $ftype;
+
+ my ($have_blame) = gitweb_check_feature('blame');
+ if (!$have_blame) {
+ die_error('403 Permission denied', "Permission denied");
+ }
+ die_error('404 Not Found', "File name not defined") if (!$file_name);
+ $hash_base ||= git_get_head_hash($project);
+ die_error(undef, "Couldn't find base commit") unless ($hash_base);
+ my %co = parse_commit($hash_base)
+ or die_error(undef, "Reading commit failed");
+ if (!defined $hash) {
+ $hash = git_get_hash_by_path($hash_base, $file_name, "blob")
+ or die_error(undef, "Error looking up file");
+ }
+ $ftype = git_get_type($hash);
+ if ($ftype !~ "blob") {
+ die_error("400 Bad Request", "Object is not a blob");
+ }
+ open ($fd, "-|", git_cmd(), "blame", '--incremental', $hash_base, '--',
+ $file_name)
+ or die_error(undef, "Open git-blame --incremental failed");
+
+ print $cgi->header(-type=>"text/plain", -charset => 'utf-8',
+ -status=> "200 OK");
+
+ while(<$fd>) {
+ if (/^([0-9a-f]{40}) ([0-9]+) ([0-9]+) ([0-9]+)/ or
+ /^author-time |^author |^filename /) {
+ print;
+ }
+ }
+
+ close $fd or print "Reading blame data failed\n";
+}
+
+sub git_blame_incremental {
+ my $fd;
+ my $ftype;
+
+ my ($have_blame) = gitweb_check_feature('blame');
+ if (!$have_blame) {
+ die_error('403 Permission denied', "Permission denied");
+ }
+ die_error('404 Not Found', "File name not defined") if (!$file_name);
+ $hash_base ||= git_get_head_hash($project);
+ die_error(undef, "Couldn't find base commit") unless ($hash_base);
+ my %co = parse_commit($hash_base)
+ or die_error(undef, "Reading commit failed");
+ if (!defined $hash) {
+ $hash = git_get_hash_by_path($hash_base, $file_name, "blob")
+ or die_error(undef, "Error looking up file");
+ }
+ $ftype = git_get_type($hash);
+ if ($ftype !~ "blob") {
+ die_error("400 Bad Request", "Object is not a blob");
+ }
+ open ($fd, "-|", git_cmd(), 'cat-file', 'blob', $hash)
+ or die_error(undef, "Open git-cat-file failed");
+ git_header_html();
+ my $formats_nav =
+ $cgi->a({-href => href(action=>"blob", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
+ "blob") .
+ " | " .
+ $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
+ "history") .
+ " | " .
+ $cgi->a({-href => href(action=>"blame", file_name=>$file_name), -class => "blamelink"},
+ "HEAD");
+ git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
+ git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_page_path($file_name, $ftype, $hash_base);
+ my @rev_color = (qw(light2 dark2));
+ my $num_colors = scalar(@rev_color);
+ my $current_color = 0;
+ my $last_rev;
+ print "<script type=\"text/javascript\" src=\"$blamejs\"></script>\n";
+ print <<HTML;
+<div class="page_body">
+<table class="blame">
+<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
+HTML
+ my %metainfo = ();
+ my $linenr = 0;
+ while (<$fd>) {
+ chomp;
+ $linenr += 1;
+ print "<tr id=\"l$linenr\" class=\"light2\">";
+ print '<td class="sha1"><a href=""></a></td>';
+ print "<td class=\"linenr\"><a class=\"linenr\" href=\"\">$linenr</a></td><td class=\"pre\">" . esc_html($_) . "</td>\n";
+ print "</tr>\n"
+ }
+
+ print "</table>\n";
+ print "</div>";
+ close $fd or print "Reading blob failed\n";
+ print "<script type=\"text/javascript\">\n";
+ print "startBlame(\"" . href(action=>"blame_data", hash_base=>$hash_base, file_name=>$file_name) . "\", \"" .
+ href(-partial_query=>1) . "\");\n";
+ print "</script>\n";
+ git_footer_html();
+}
+
+
sub git_blame2 {
my $fd;
my $ftype;
@@ -3609,7 +3729,7 @@ sub git_blame2 {
$cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
"history") .
" | " .
- $cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blame", file_name=>$file_name), -class => "blamelink"},
"HEAD");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
@@ -3711,7 +3831,7 @@ sub git_blame {
$cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
"history") .
" | " .
- $cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blame", file_name=>$file_name), -class => "blamelink"},
"HEAD");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
@@ -3884,7 +4004,7 @@ sub git_blob {
if ($have_blame) {
$formats_nav .=
$cgi->a({-href => href(action=>"blame", hash_base=>$hash_base,
- hash=>$hash, file_name=>$file_name)},
+ hash=>$hash, file_name=>$file_name), -class => "blamelink"},
"blame") .
" | ";
}
@@ -5179,7 +5299,7 @@ XML
-title => "diff"}, 'D');
if ($have_blame) {
print $cgi->a({-href => href(-full=>1, action=>"blame",
- file_name=>$file, hash_base=>$commit),
+ file_name=>$file, hash_base=>$commit), -class => "blamelink",
-title => "blame"}, 'B');
}
# if this is not a feed of a file history
^ permalink raw reply related
* Re: [PATCH] gitweb: Incremental blame
From: Petr Baudis @ 2007-05-18 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Fredrik Kuivinen
In-Reply-To: <20070518151502.27621.36135.stgit@rover>
On Fri, May 18, 2007 at 05:15:02PM CEST, Petr Baudis wrote:
> Compared to the original patch, this one works with pathinfo-ish URLs as
> well, and should play well with non-javascript browsers as well (the HTML
> points to the blame action, while javascript code rewrites the links to use
> the blame_incremental action; it is somewhat hackish but I couldn't think
> of a better solution).
To make it more clear, the additional changes in this patch are really
totally trivial (except the link rewriting javascript code, which is
rather simple too and I spent only two happy hours of my life debugging
it) - maybe I should've kept Fredrik signed off and maybe even the patch
author and add just my signoff. I'm not really sure how the procedures
should work here.
--
Petr "Pasky the I HATE THE
!@#*($!*(^%@#*$233.. JAVASCRIPT!!!!!!!!" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Aidan Van Dyk @ 2007-05-18 15:06 UTC (permalink / raw)
To: Michael S. Tsirkin, git, Josef Weidendorfer, Michael S. Tsirkin,
Junio C Hamano, Nicolas Pitre, Andy Parkins
In-Reply-To: <20070518110804.GD4708@mellanox.co.il>
Michael S. Tsirkin wrote:
>> Quoting Andy Parkins <andyparkins@gmail.com>:
>> Subject: Re: [3/4] What's not in 1.5.2 (new topics)
>>
>> On Friday 2007 May 18, Josef Weidendorfer wrote:
>>
>> > It all depends on how we construct the default URL out of the
>> > subproject identifier. Options:
>> > (1) do not try to construct a default URL at all. Error out without a
>> > config (2) use a configurable rewriting scheme like
>> > s/(.*)/git://host/\1/ (3) automatically detect a senseful rewriting
>> > scheme
>> >
>> > Let's start with (1). We can invent convenient default schemes later
>> > on.
>>
>> All good; except let's start with
>>
>> (1) if no config, try using the key itself - error out if that fails
>>
>> Then everybody is happy - if you want to use your system where the key is
>> not
>> a URL, then don't - you'll get the error you want. If the user chose to
>> use a URL then magic will happen.
>
> I don't want an error. No one wants an error.
>
> I want to be able to clone a super project, a subproject,
> and use my copy of both instead of the original - including
> cloning my copy, pulls between such clones, being able to verify
> that they are identical.
>
> What I *don't* want is a situation where the fact that original repository
> resides in north america necessarily means that everyone who looks at *my*
> clone of it will do a round trip to north america too.
Again - if *I* create a project, and decide to use a particular key for a
subproject, then good. If *you* create a project and decide to use a
particular key for a subproject, then good.
If you clone *my* superproject, you get *my* choice of key. If I clone
*your* superproject, I get *your* choice of key.
The fact that I can choose a URL as my key is in no way influencing the fact
that you can choose to *not* use a URL for your key.
And if if you want to "copy" my project, but "change" the key for the
subproject, that's something you can too to! In GIT, that's a branch.
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-18 15:31 UTC (permalink / raw)
To: Aidan Van Dyk
Cc: Michael S. Tsirkin, git, Josef Weidendorfer, Junio C Hamano,
Nicolas Pitre, Andy Parkins
In-Reply-To: <20070518151044.2FC05111E33@yugib.highrise.ca>
> Again - if *I* create a project, and decide to use a particular key for a
> subproject, then good. If *you* create a project and decide to use a
> particular key for a subproject, then good.
>
> If you clone *my* superproject, you get *my* choice of key. If I clone
> *your* superproject, I get *your* choice of key.
Absolutely. What I object to is using this key in clients
as a hint for where to get the objects.
This *must* be overridable by me, without creating commits.
--
MST
^ permalink raw reply
* [PATCH] StGIT: Support Cc: fields in stg mail --auto
From: Petr Baudis @ 2007-05-18 15:33 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Aside of Signed-off-by and Acked-by fields, Cc fields may occur in the
message footer; include them in the auto-composed mail Cc list.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
stgit/commands/mail.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 151a408..97deb3e 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -223,7 +223,7 @@ def __get_signers_list(msg):
"""
addr_list = []
- r = re.compile('^(signed-off-by|acked-by):\s+(.+)$', re.I)
+ r = re.compile('^(signed-off-by|acked-by|cc):\s+(.+)$', re.I)
for line in msg.split('\n'):
m = r.match(line)
if m:
^ permalink raw reply related
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Petr Baudis @ 2007-05-18 16:08 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Michael S. Tsirkin, Jakub Narebski, Junio C Hamano, Andy Parkins,
Nicolas Pitre, git
In-Reply-To: <200705181751.15435.Josef.Weidendorfer@gmx.de>
On Fri, May 18, 2007 at 05:51:14PM CEST, Josef Weidendorfer wrote:
> On Friday 18 May 2007, Michael S. Tsirkin wrote:
> > > Subproject identifiers appear in versioned .gitmodule files, so
> > > they are fixed with the history of the project. You can not change
> > > the names without rewriting history.
> >
> > Actually, I think this means that moving the
> > directory where the subproject resides will involve
> > editing .gitmodule. I sthat true?
>
> Yes.
> This was a design decision by Linus. The alternative way
> would have been a separate gitlink object, which includes the
> commit SHA1 of the subproject _and_ a subproject identifier,
> thus increasing the number of objects.
>
> The current way is far simpler, but you have to edit the .gitmodule
> file when moving subprojects around. The argument by Linus was
> that this inconvenience should be acceptable as moving subprojects
> around should only happen very few times in the lifetime of a
> project, and involves heavy rearranging either way, such that editing
> .gitmodules info is the smaller issue.
Furthermore, git mv can trivially take care of this anyway...
> > This would be annoying.
> >
> > Can't a project name be a git attribute for the gitlink object?
>
> Of course. The name can be put into the .gitattributes file instead of
> a separate .gitmodules file.
>
> > This way I can move the object and it keeps the project name.
>
> No.
> Git attributes do not magically move around when you move files or
> directories. You always have to change the .gitattribute file too, if
> you want to move attributes with files. Of course, this is not needed
> if you use glob patterns in .gitattributes which also fits for moved
> files.
Actually, git-mv might take care of this too? ;-) (Would it be
considered a Bad Thing, or should I whip up a patch?)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-18 16:21 UTC (permalink / raw)
To: Petr Baudis
Cc: Josef Weidendorfer, Michael S. Tsirkin, Jakub Narebski,
Junio C Hamano, Andy Parkins, Nicolas Pitre, git
In-Reply-To: <20070518160840.GK18276@pasky.or.cz>
> > The current way is far simpler, but you have to edit the .gitmodule
> > file when moving subprojects around. The argument by Linus was
> > that this inconvenience should be acceptable as moving subprojects
> > around should only happen very few times in the lifetime of a
> > project, and involves heavy rearranging either way, such that editing
> > .gitmodules info is the smaller issue.
>
> Furthermore, git mv can trivially take care of this anyway...
Good idea.
--
MST
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Junio C Hamano @ 2007-05-18 17:00 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Andy Parkins, git, Michael S. Tsirkin, Nicolas Pitre,
Steven Grimm
In-Reply-To: <200705181043.09203.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Friday 18 May 2007, Andy Parkins wrote:
>> Bear in mind that what you're suggesting is no different in implementation
>> >from what Junio is suggesting but with one difference: in Junio's option
>> the "identifier" will act as a default URL if no override is found.
>
> Yes; actually, its exactly the same aside from the name used in .gitmodules
> for it, as I proposed a default URL which is derived from the suproject identifier
> if no config entry is found.
>
>> > Again, we could have a default URL in the absence of this config entry
>> > which is relative to the URL of the superproject, and which allows for the
>> > superproject repository to act as proxy.
>>
>> This is why Junio's option of URL=Key is better.
There is one thing that three-level thing Steven Grimm suggested
solves cleaner that my strawman would not.
If the superproject is about building a live-cd that hosts two
different systems, one BSD and the other Linux, you would have:
kernel-bsd/ subproject pointing at http://some.bsd.org/
kernel-linux/ pointing at http://www.kernel.org/kernel/
Now suppose kernel.org people forgot to renew the domain
registration and BSD people are quick to react, takes over the
nice "kernel.org" domain, and now the latter URL becomes a site
about the BSD kernel---what happens? ;-) URL=Key scheme uses the
URL as the key so newer kernel-bsd/ subproject may be pointed at
by http://www.kernel.org/kernel/ in the superproject after such
a transition. Linux kernel wouldn't cease to be served, so
in your .git/config you will a map to tell git to fetch from the
new location http://www.linux-kernel.org/kernel, but what key
would you use? Using http://www.kernel.org/kernel/ would not be
correct as it would work only for older parts of the history.
Newer part of the history would want to map the same URL (=Key)
to http://www.kernel.org/kernel which is now hosting the BSD
kernel.
In short, you would need to be able to express the "intent" in
the .gitmodules and say "I am talking about the Linux kernel
with this entry", and if the same URL used for that purpose is
ever retargetted to house something different that is also used
in your superproject, URL=Key scheme is screwed.
Also I would be lying if I said I do not like the three-level
thing --- that was one of the options I considered before the
URL=Key thing. Steven's three-level thing does not have the
above problem (but there is one thing you need to be careful
about, which I'll mention at the end of this discussion).
> It all depends on how we construct the default URL out of the subproject
> identifier. Options:
> (1) do not try to construct a default URL at all. Error out without a config
> (2) use a configurable rewriting scheme like s/(.*)/git://host/\1/
> (3) automatically detect a senseful rewriting scheme
>
> Let's start with (1). We can invent convenient default schemes later on.
My preference is to stay at (1), and even if we are to do the
later steps, do it _always_ with confirmation from the user.
Fetching from a new URL (not just "different from what is
defined in .gitmodules") is a major deal from security point of
view (you should not fetch from stranger you do not trust).
There is one thing that I sense was misunderstood by some people
about my original strawman. Entries in .git/config are _not_
used as an override. They _are_ the only thing that are used.
Let's forget the above "BSD takes over kernel.org" example,
which was a tongue-in-cheek, and go back to the original
appliance release #1 and #2 uses kernel 2.4 and 2.6 example.
When you see this in .gitmodule:
[subproject "kernel/"]
URL = git://git.kernel.org/pub/linux-2.4.git
you can be in three states:
(1) You haven't known about this subproject's URL.
(2) You have already known about this subproject, and you
earlier decided not to clone it nor check it out (i.e. in
your working tree, kernel/ subdirectory is left empty).
By default, you do not want to be bothered by this
subproject.
(3) You have known about this subproject, and you earlier
decided that you are interested in it. You have a
repository and working tree that represents the subproject
checked out in your kernel/ subdirectory. By default, you
want to keep track of this subproject.
Obviously in the initial-clone case you can only be in state
(1). After the initial clone, if the upstream changed the
kernel/ binding to point at 2.6 kernel tree, you are also in the
same state (1).
In these cases, since the upstream clearly states that they are
now talking about a project unknown to you so far, or talking
about a different project (it could be just a new location for
the same thing, the case Steven's three-level thing can help you
to differenciate with this), I DO NOT want git to automatically
say "Ok, that's the new location" and blindly start following.
An unattended pull (actually, the checkout step after a pull)
SHOULD error out.
An interactive case should give an easy way for the user to
express his preference: (a) I do not care about this subproject,
(b) I do want to have this cloned and checked out, and the
suggested URL in .gitmodules would work fine for me, or (c) I do
want to have this, but I want to use this other URL because I
have a local mirror already.
I wrote in my original strawman to have these two entries in the
.git/config file:
[subproject "git://git.kernel.org/pub/linux-2.4.git"]
URL = http://www.kernel.org/pub/linux-2.4.git
The example mapped the URL=Key to a different URL, which gave a
false impression that I was only talking about override, but
that was my fault. My intention was to use the _presense_ of
subproject.$URL section in .git/config as a way to detect state
(1), so when the user says "I do want to follow this subproject
and the .gitmodules URL is Ok" (iow, choice (b) above), you
would have an identical "mapping" there:
[subproject "git://git.kernel.org/pub/linux-2.4.git"]
URL = git://git.kernel.org/pub/linux-2.4.git
That's not an "override". Lack of these two lines does not mean
you will blindly follow kernel/ subproject using the URL
recorded in .gitmodules file; it means you haven't decided what
to do about the kernel/ subproject yet.
If the user wants to say "I am not interested" (iow, choice (a)
above), we would not have URL section, but explicit variable to
say "I am not interested" there, like this:
[subproject "git://git.kernel.org/pub/linux-2.4.git"]
ignored
Then the presense of this section tells us that we are not in
state (1) about this subproject.
The above can easily be rewritten to use Steven's three-level
scheme, which I tend to think would work better. But if we were
to do that, I think the .git/config section should give you a
way to differentiate not just known/unknown subprojects but also
a way to differentiate known/unknown URLs.
IOW, .gitmodules in three-level scheme might say:
[subproject "kernel/"]
name = linux-2.6
URL = git://git.kernel.org/pub/linux-2.6.git
and your .git/config would say:
[subproject "linux-2.6"]
URL = http://www.kernel.org/pub/linux-2.6.git
seen = git://git.kernel.org/pub/linux-2.6.git
so that when the upstream .gitmodules changed the suggested URL
to "git://git.or.cz/pub/linux-2.6.git", the UI can say:
The project uses "linux-2.6" project at kernel/
subdirectory as subproject, we already know that you are
interested in tracking it, that you have been tracking
it with http://www.kernel.org/pub/linux-2.6.git URL.
The upstream suggests a new URL you haven't seen, which is
"git://git.or.cz/pub/linux-2.6.git". Do you want to
adjust the URL to follow this subproject?
The user may say yes and tell git to use http:// instead, in
which case the section in .git/config would become:
[subproject "linux-2.6"]
URL = http://git.or.cz/pub/linux-2.6.git
seen = git://git.kernel.org/pub/linux-2.6.git
seen = git://git.or.cz/pub/linux-2.6.git
After that, if the upstream wags the entry .gitmodules back to
point at git.kernel.org/, you already know about that repository
and the UI does not have to ask you what to do about it. That's
made possible by using URL=Key in my strawman, but needs to be
done by this extra 'seen' multi-value variables in the three-level
scheme.
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Jan Hudec @ 2007-05-18 17:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Petr Baudis, git
In-Reply-To: <alpine.LFD.0.99.0705171633440.24220@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
On Thu, May 17, 2007 at 16:38:41 -0400, Nicolas Pitre wrote:
> On Thu, 17 May 2007, Jan Hudec wrote:
>
> > A particular case would be a group of students wanting to publish their
> > software project (I mean the PRG023 or equivalent). Private computers in the
> > hostel are not allowed to serve anything, so they'd use some of the lab
> > servers (eg. artax, ss1000...). All of them allow full CGI, but running
> > daemons is forbiden.
>
> And wouldn't the admin authority for those lab servers be amenable to
> install a Git daemon service? That'd be a much better solution to me.
It would. But it would really depend on the administrator goodwill.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Jan Hudec @ 2007-05-18 17:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Shawn O. Pearce, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0705180958390.6410@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]
On Fri, May 18, 2007 at 10:01:52 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 17 May 2007, Jan Hudec wrote:
>
> > On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:
> >
> > > And if you have 1) the permission and 2) the CPU power to execute such
> > > a cgi on the server and obviously 3) the knowledge to set it up
> > > properly, then why aren't you running the Git daemon in the first
> > > place? After all, they both boil down to running git-pack-objects and
> > > sending out the result. I don't think such a solution really buys
> > > much.
> >
> > Yes, it does. I had 2 accounts where I could run CGI, but not separate
> > server, at university while I studied and now I can get the same on
> > friend's server. Neither of them would probably be ok for serving larger
> > busy git repository, but something smaller accessed by several people is
> > OK. I think this is quite common for university students.
>
> 1) This has nothing to do with the way the repo is served, but how much
> you advertise it. The load will not be lower, just because you use a CGI
> script.
That won't. But that was never the purpose of "smart cgi". The purpose was to
minimize the bandwidth usage (and connectivity is still not so cheap that
you'd not care) while still working over http either because the users need
to access it from behind firewall or because administrator is not willing to
set up git-daemon for you, while CGI you can run yourself.
> 2) you say yourself that git-daemon would have less impact on the load:
NO, I didn't -- at least not in the paragraph below.
In the below paragraph I said, that *network* use will never be as good with
*dumb* solution, as it can be with smart solution, no matter whether it is
over special protocol or HTTP.
---
Of course it would be less efficient in both CPU and network load, because
there is the overhead of the web server and overhead of the http headers.
Actually I like the ranges solution. If accompanied with repack stategy that
does not pack everything together, but instead creates packs of limited
number of objects -- so that the indices don't exceed configurable size, say
64kB -- could not so much less efficient for the network and have the
advantage of working without ability to execute CGI.
> > > [...]
> > >
> > > Et voilà. Oh, and of course update your local refs from the
> > > remote's.
> > >
> > > Actually there is nothing really complex in the above operations. And
> > > with this the server side remains really simple with no special setup
> > > nor extra load beyond the simple serving of file content.
> >
> > On the other hand the amount of data transfered is larger, than with the
> > git server approach, because at least the indices have to be transfered
> > in entirety.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Linus Torvalds @ 2007-05-18 18:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqlkfnipjl.fsf@bauges.imag.fr>
On Thu, 17 May 2007, Matthieu Moy wrote:
>
> Many (if not most?) of the people working in a big company, I'd say.
> Year, it sucks, but people having used a paranoid firewall with a
> not-less-paranoid and broken proxy understand what I mean.
Well, we could try to support the git protocol over port 80..
IOW, it's probably easier to try to get people to use
git clone git://some.host:80/project
and just run git-daemon on port 80, than it is to try to set of magic cgi
scripts etc.
Doing that with virtual hosts etc should be pretty trivial. Much more so
than trying to make a git-cgi script.
And yes, I do realize that in theory you can have http-aware firewalls
that expect to see the normal http sequences in the first few packets in
order to pass things through, but I seriously doubt it's very common.
Linus
^ permalink raw reply
* Re: [PATCH] Fix crlf attribute handling to match documentation
From: Junio C Hamano @ 2007-05-18 18:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705181333.32719.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> gitattributes.txt says, of the crlf attribute:
> ...
> However, that is not what convert.c was doing.
Thanks. I'll take a look later.
Some addition to the existing test t/t0020-crlf.sh to
demonstrate this bug and your fix would be appropriate.
^ permalink raw reply
* Re: merge summaries
From: Linus Torvalds @ 2007-05-18 18:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <25A3C618-8D12-42A8-9478-D3A4E7633CE7@zib.de>
On Fri, 18 May 2007, Steffen Prohaska wrote:
>
> It took me some time to figure out how to get summaries of the merged branch
> into merge messages. Finally I recognized that I simply need to set
>
> git-config merge.summary true
Yes.
> I have two questions:
> 1) Why isn't 'true' the default setting? The two probably most prominent git
> repositories, git and kernel, both use merge summaries.
Think about _who_ uses it for those two prominent repositories for a while.
[ pause, ponder here ]
In other words, "merge.summary" should be true ONLY FOR TOP-LEVEL
MAINTAINERS.
Making it true for anybody else is almost always a bug. Yes, I and Junio
have it enabled, but pretty much nobody else should, because if they pull
from me or Junio in order to merge, their merge summaries would be exactly
the wrong way around!
> 2) Why does git-merge have a switch '--no-summary' to switch summaries off,
> but doesn't have a switch '--summary' to switch them on?
Probably because "normal users" should never use summaries in the first
place, so it's just not been an issue.
Linus
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Junio C Hamano @ 2007-05-18 18:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f2k4g6$879$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> [Cc: Petr Baudis <pasky@suse.cz>, Josef Weidendorfer
> <Josef.Weidendorfer@gmx.de>, "Michael S. Tsirkin" <mst@dev.mellanox.co.il>,
> Junio C Hamano <junkio@cox.net>, Andy Parkins <andyparkins@gmail.com>,
> Nicolas Pitre <nico@cam.org>, git@vger.kernel.org]
Offtopic. Why do you do this, and what benefit are you or
anybody in the above list, which is in body part of the message,
getting?
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Julian Phillips @ 2007-05-18 18:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vwsz65679.fsf@assigned-by-dhcp.cox.net>
On Fri, 18 May 2007, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> [Cc: Petr Baudis <pasky@suse.cz>, Josef Weidendorfer
>> <Josef.Weidendorfer@gmx.de>, "Michael S. Tsirkin" <mst@dev.mellanox.co.il>,
>> Junio C Hamano <junkio@cox.net>, Andy Parkins <andyparkins@gmail.com>,
>> Nicolas Pitre <nico@cam.org>, git@vger.kernel.org]
>
> Offtopic. Why do you do this, and what benefit are you or
> anybody in the above list, which is in body part of the message,
> getting?
It looks like he is posting through gmane using a news reader ... so the
list post comes from gmane while the CCs go out directly (I assume).
--
Julian
---
Green's Law of Debate:
Anything is possible if you don't know what you're talking about.
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Junio C Hamano @ 2007-05-18 18:45 UTC (permalink / raw)
To: Julian Phillips; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0705181939250.14963@beast.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Fri, 18 May 2007, Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> [Cc: Petr Baudis <pasky@suse.cz>, Josef Weidendorfer
>>> <Josef.Weidendorfer@gmx.de>, "Michael S. Tsirkin" <mst@dev.mellanox.co.il>,
>>> Junio C Hamano <junkio@cox.net>, Andy Parkins <andyparkins@gmail.com>,
>>> Nicolas Pitre <nico@cam.org>, git@vger.kernel.org]
>>
>> Offtopic. Why do you do this, and what benefit are you or
>> anybody in the above list, which is in body part of the message,
>> getting?
>
> It looks like he is posting through gmane using a news reader ... so
> the list post comes from gmane while the CCs go out directly (I
> assume).
Ah, I see. The names listed on that in-body CC: do appear on
the To: in the copy of the message that came via e-mail. If
that is how gmane operates then there is nothing Jakub to do to
improve it, I guess...
Thanks for the clarification.
^ permalink raw reply
* Re: merge summaries
From: Junio C Hamano @ 2007-05-18 18:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705181130580.3890@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>> I have two questions:
>> 1) Why isn't 'true' the default setting? The two probably most prominent git
>> repositories, git and kernel, both use merge summaries.
>
> Think about _who_ uses it for those two prominent repositories for a while.
>
> [ pause, ponder here ]
>
> In other words, "merge.summary" should be true ONLY FOR TOP-LEVEL
> MAINTAINERS.
>
> Making it true for anybody else is almost always a bug. Yes, I and Junio
> have it enabled, but pretty much nobody else should, because if they pull
> from me or Junio in order to merge, their merge summaries would be exactly
> the wrong way around!
This does not necessarily mean that your lieutenants should not
use merge.summary when they pull from other trees (or inside
their own repository to merge in the topics). They need to
however disable it with --no-summary when they pull from you
when they choose to merge instead of rebase to adjust to the
updated infrastructure in your tree.
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: alan @ 2007-05-18 18:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthieu Moy, git
In-Reply-To: <alpine.LFD.0.98.0705181123590.3890@woody.linux-foundation.org>
On Fri, 18 May 2007, Linus Torvalds wrote:
>
>
> On Thu, 17 May 2007, Matthieu Moy wrote:
>>
>> Many (if not most?) of the people working in a big company, I'd say.
>> Year, it sucks, but people having used a paranoid firewall with a
>> not-less-paranoid and broken proxy understand what I mean.
>
> Well, we could try to support the git protocol over port 80..
>
> IOW, it's probably easier to try to get people to use
>
> git clone git://some.host:80/project
>
> and just run git-daemon on port 80, than it is to try to set of magic cgi
> scripts etc.
Except some filtering firewalls try and strip content from data (like
ActiveX controls.)
Running git on port 53 will bypass pretty much every firewall out there.
(If you want to learn how to bypass an overactive firewall, talk to a
bunch of teenagers at a school with an agressive porn filter.)
--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Joel Becker @ 2007-05-18 19:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthieu Moy, git
In-Reply-To: <alpine.LFD.0.98.0705181123590.3890@woody.linux-foundation.org>
On Fri, May 18, 2007 at 11:27:22AM -0700, Linus Torvalds wrote:
> Well, we could try to support the git protocol over port 80..
>
> IOW, it's probably easier to try to get people to use
>
> git clone git://some.host:80/project
>
> and just run git-daemon on port 80, than it is to try to set of magic cgi
> scripts etc.
Can we tech the git-daemon to parse the HTTP headers
(specifically, the URL) and return the appropriate HTTP response?
> And yes, I do realize that in theory you can have http-aware firewalls
> that expect to see the normal http sequences in the first few packets in
> order to pass things through, but I seriously doubt it's very common.
It's not about packet scanning, it's about GET vs CONNECT. If
the proxy allows GET but not CONNECT, it's going to forward the HTTP
protocol to the server, and git-daemon is going to see "GET /project
HTTP/1.1" as its first input. Now, perhaps we can cook that up behind
some apache so that apache handles vhosting the URL, then calls
git-daemon which can take the stdin. So we'd be doing POST, not GET.
On the other hand, if the proxy allows CONNECT, there is no
scanning for HTTP sequences done by the proxy. It just allows all raw
data (as it figures you're doing SSL).
A normal company needs to have their firewall allow CONNECT to
9418. Then git proxying over HTTP is possible to a standard git-daemon.
Joel
--
"The first requisite of a good citizen in this republic of ours
is that he shall be able and willing to pull his weight."
- Theodore Roosevelt
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ 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