* [PATCH 0/2] gitweb: blame: make cut-and-paste legible
From: Luben Tuikov @ 2006-10-05 0:57 UTC (permalink / raw)
To: git
The following set of patches makes cut-and-paste from blame
legible in the destination buffer. E.g.:
cae1862a 3033 if (defined $co{'parent'}) {
3034 push @views_nav,
3035 $cgi->a({-href => href(action=>"shortlog", hash=>$hash)}, "shortlog"),
3036 $cgi->a({-href => href(action=>"log", hash=>$hash)}, "log");
3037 }
It also adds "title" to all rows of data.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Luben Tuikov @ 2006-10-05 0:15 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <7vzmcdpwso.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> BTW,
>
> - why do we have shortlog and log twice in the top navigation
> bar in commit view (a=commit)?
It appears to be in the $extra argument to git_print_page_nav()
from git_commit() from cae1862a, lines 3033-3037.
Luben
>
> - sometimes I'd like to view my tags sorted by name not by
> age. Maybe we could add <sort-by> control on the age and
> name columns for git_tags_body()?
>
>
>
^ permalink raw reply
* Re: asciidoc 7--8 compatibility
From: Stuart Rackham @ 2006-10-04 23:40 UTC (permalink / raw)
To: Stefan Richter; +Cc: Junio C Hamano, git
In-Reply-To: <4524343B.8060709@s5r6.in-berlin.de>
Stefan Richter wrote:
> Stuart Rackham wrote:
>> --- asciidoc.conf (revision 53)
>> +++ asciidoc.conf (working copy)
>> @@ -62,9 +62,9 @@
>> __=#emphasis
>> ++=#monospaced
>> \##=#unquoted
>> -endif::asciidoc7compatible[]
>> ^=#superscript
>> ~=#subscript
>> +endif::asciidoc7compatible[]
>
> Could git/Documentation/asciidoc.conf just kill all the various meanings
> of +, ~, ^ and make them into regular characters? In a way that works
> with all versions of asciidoc?
[quotes]
^=
~=
+=
From the AsciiDoc User Guide: "A configuration file [quotes] entry can
be subsequently undefined by setting it to a blank value."
>
> (Frankly, using + as a special character may sound like a neat idea if
> all one wants to do is to typeset poems.)
The rationale for the + is discussed in the AsciiDoc changelog
(http://www.methods.co.nz/asciidoc/CHANGELOG.html). It also brings
AsciiDoc in line with the Ruby RDoc source code documentation system syntax.
--
Stuart Rackham
^ permalink raw reply
* Re: asciidoc 7--8 compatibility
From: Stefan Richter @ 2006-10-04 22:22 UTC (permalink / raw)
To: Stuart Rackham; +Cc: Junio C Hamano, git
In-Reply-To: <4524226D.5000305@methods.co.nz>
Stuart Rackham wrote:
> --- asciidoc.conf (revision 53)
> +++ asciidoc.conf (working copy)
> @@ -62,9 +62,9 @@
> __=#emphasis
> ++=#monospaced
> \##=#unquoted
> -endif::asciidoc7compatible[]
> ^=#superscript
> ~=#subscript
> +endif::asciidoc7compatible[]
Could git/Documentation/asciidoc.conf just kill all the various meanings
of +, ~, ^ and make them into regular characters? In a way that works
with all versions of asciidoc?
(Frankly, using + as a special character may sound like a neat idea if
all one wants to do is to typeset poems.)
--
Stefan Richter
-=====-=-==- =-=- --=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: asciidoc 7--8 compatibility (was Re: pull-fetch-param.txt)
From: Stuart Rackham @ 2006-10-04 21:06 UTC (permalink / raw)
To: Stefan Richter; +Cc: Junio C Hamano, git
In-Reply-To: <4523E401.5080709@s5r6.in-berlin.de>
[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]
Hi Stefan
Stefan Richter wrote:
> Stuart Rackham wrote:
>> From the AsciiDoc User Guide
>> (http://www.methods.co.nz/asciidoc/userguide.html#X53):
>>
>> If you want to disable unconstrained quotes, the new alternative
>> constrained quotes syntax and the new index entry syntax then you can
>> define the attribute asciidoc7compatible (for example by using the -a
>> asciidoc7compatible command-line option).
>
> Stuart,
>
> the actual issues were:
>
> 1.) Input which works with asciidoc 7 fails to build with asciidoc 8
> (after the intermediary XML step). This pair of tildes broke (but other
> occurences of tilde did not):
>
> | * A suffix '~<n>' to a revision parameter means the commit
> | object that is the <n>th generation grand-parent of the named
> | commit object, following only the first parent. I.e. rev~3 is
I've conditionally redefined subscript (tilde) and superscripting so
they use the old replacements mechanism when asciidoc7compatible is
defined rather than the asciidoc 8 default unconstrained quoting (patch
for affected files attached).
>
> 2.) Asciidoc 8 silently swallows characters from input which works with
> asciidoc 7. The two pluses in the following line vanished (but instances
> of single pluses per input line did not vanish):
>
> | `+?<src>:<dst>`; that is, an optional plus `+`, followed
Fixed by asciidoc7compatible.
>
> I wonder:
>
> - Are tilde and plus new special characters in asciidoc 8, or were they
> already special characters in asciidoc 7?
> [ A pair of single pluses encloses monospaced text in asciidoc 8.
> A pair of single tildes encloses subscripts. ]
>
> - If they were already special characters in asciidoc 7, what is the
> canonical way to escape them in asciidoc 7, 8, and hopefully 9?
> [ If they weren't special characters in asciidoc 7, then we need
> to use the asciidoc7compatible attribute. ]
>
> - Does asciidoc 7 accept the asciidoc7compatible attribute?
No.
>
> Thanks.
>
>
> PS:
>
> Junio, Stuart, here is another inconsistency between asciidoc 7 and 8.
> Please have a look at
> http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html .
> See the ASCII art above "SPECIFYING RANGES". The input
> \ | / \
> \ | / |
> produced
> \ | / \ | / |
> I.e. backslash-newline was interpreted by asciidoc 7 (or whatever you
> use to generate what is put online) as an escaped thus swallowed
> newline. But the output that I got here from asciidoc 8 (manpage as well
> as the html file) still has backslash and newline printed out.
Cheers, Stuart
[-- Attachment #2: asciidoc.patch --]
[-- Type: text/plain, Size: 1621 bytes --]
Index: asciidoc.conf
===================================================================
--- asciidoc.conf (revision 53)
+++ asciidoc.conf (working copy)
@@ -62,9 +62,9 @@
__=#emphasis
++=#monospaced
\##=#unquoted
-endif::asciidoc7compatible[]
^=#superscript
~=#subscript
+endif::asciidoc7compatible[]
[specialwords]
emphasizedwords=
Index: xhtml11.conf
===================================================================
--- xhtml11.conf (revision 53)
+++ xhtml11.conf (working copy)
@@ -22,6 +22,12 @@
\$=\$
`=\`
endif::asciimath[]
+ifdef::asciidoc7compatible[]
+# Superscripts.
+\^(.+?)\^=<sup>\1</sup>
+# Subscripts.
+~(.+?)~=<sub>\1</sub>
+endif::asciidoc7compatible[]
[ruler-blockmacro]
<hr />
Index: docbook.conf
===================================================================
--- docbook.conf (revision 53)
+++ docbook.conf (working copy)
@@ -18,6 +18,12 @@
[replacements]
# Line break markup is dropped (there is no DocBook line break tag).
(?m)^(.*)\s\+$=\1
+ifdef::asciidoc7compatible[]
+# Superscripts.
+\^(.+?)\^=<superscript>\1</superscript>
+# Subscripts.
+~(.+?)~=<subscript>\1</subscript>
+endif::asciidoc7compatible[]
[ruler-blockmacro]
# Only applies to HTML so don't output anything.
Index: html4.conf
===================================================================
--- html4.conf (revision 53)
+++ html4.conf (working copy)
@@ -18,6 +18,12 @@
[replacements]
# Line break.
(?m)^(.*)\s\+$=\1<br />
+ifdef::asciidoc7compatible[]
+# Superscripts.
+\^(.+?)\^=<sup>\1</sup>
+# Subscripts.
+~(.+?)~=<sub>\1</sub>
+endif::asciidoc7compatible[]
[ruler-blockmacro]
<hr />
^ permalink raw reply
* Re: pull-fetch-param.txt
From: Stefan Richter @ 2006-10-04 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, srackham
In-Reply-To: <4523E120.6050007@s5r6.in-berlin.de>
I wrote:
> Junio C Hamano wrote:
>> Can you try reformatting the original
>>
>>> <refspec>::
>>> The canonical format of a <refspec> parameter is
>>> `+?<src>:<dst>`; that is, an optional plus `+`, followed
>>> by the source ref, followed by a colon `:`, followed by
>>> the destination ref.
>> to something like
>>
>>> <refspec>::
>>> The canonical format of a <refspec> parameter is
>>> `+?<src>:<dst>`; that is, an optional plus
>>> `+`, followed
>>> by the source ref, followed by a colon `:`, followed by
>>> the destination ref.
>> and verify that conjecture?
>
> This hack does not help. The two `+` are still absent from the manpage
> (but as before, the `+` in the next paragraph is printed as desired).
After a few more experiments with different placements of backticks et
cetera, I found only the following variants to work with asciidoc 8:
(as mentioned, not compatible to asciidoc 7):
`$$+$$?<src>:<dst>`; that is, an optional plus `+`, followed
(as mentioned, compatible)
`\+?<src>:<dst>`; that is, an optional plus `+`, followed
(also OK, and this is probably the only really correct syntax)
`\+?<src>:<dst>`; that is, an optional plus `\+`, followed
(also OK but misses the monospace formatting on the plus or on the plus
and questionmark)
\+`?<src>:<dst>`; that is, an optional plus `+`, followed
\+?`<src>:<dst>`; that is, an optional plus `+`, followed
\+?`<src>:<dst>`; that is, an optional plus \+, followed
`\+?<src>:<dst>`; that is, an optional plus +, followed
Note,
`+``?<src>:<dst>`; that is, an optional plus `+`, followed
does _not_ work. It stops on invalid syntax in the intermediary xml
file. Also
+\+?<src>:<dst>+; that is, an optional plus `+`, followed
or
`+`+?<src>:<dst>+; that is, an optional plus `+`, followed
do _not_ work. They don't print what we want to see.
--
Stefan Richter
-=====-=-==- =-=- --=--
http://arcgraph.de/sr/
^ permalink raw reply
* git-send-email w/ headers
From: Len Brown @ 2006-10-04 16:50 UTC (permalink / raw)
To: git
git-send-email seems to strip out my custom headers.
git-format-patch says it can do this:
CONFIGURATION
You can specify extra mail header lines to be added to each message in the repository configuration as follows:
headers = "Organization: git-foo\n"
So I have this:
$ cat .git/config
[format]
headers = Reply-To: Len Brown <lenb@kernel.org>\nOrganization: Intel Open Source Technology Center\n
$ git-format-patch -o foo -n --thread master..lenb
seems to correctly pick up the headers:
$ cat foo/0001-test-create-junk.txt
From 6706b39a213064d00af0ec58a159b71b0719a3b4 Mon Sep 17 00:00:00 2001
Message-Id: <6706b39a213064d00af0ec58a159b71b0719a3b4.1159941986.git.len.brown@intel.com>
From: Len Brown <len.brown@intel.com>
Reply-To: Len Brown <lenb@kernel.org>
Organization: Intel Open Source Technology Center
Date: Wed, 4 Oct 2006 01:11:12 -0400
Subject: [PATCH 1/14] test: create junk
Signed-off-by: Len Brown <len.brown@intel.com>
---
junk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/junk b/junk
new file mode 100644
index 0000000..9ecf3cf
--- /dev/null
+++ b/junk
@@ -0,0 +1 @@
+this
--
1.4.2.3.g128e
$ git-send-email --no-chain-reply-to --compose --to lenb@kernel.org --smtp-server smpt.comcast.net --suppress-from foo
and i receive a message w/o the Organization and Reply-to headers:
$ cat ~/Documents/test.e-mail-received
From len.brown@intel.com Wed Oct 4 12:34:51 2006
Return-Path: <len.brown@intel.com>
Received: from alnrmhc12.comcast.net (alnrmhc12.comcast.net [206.18.177.52])
by hera.kernel.org (8.13.7/8.13.7) with ESMTP id k94GVifO030722
for <lenb@kernel.org>; Wed, 4 Oct 2006 16:32:17 GMT
Received: from localhost.localdomain (c-65-96-213-102.hsd1.ma.comcast.net[65.96.213.102])
by comcast.net (alnrmhc12) with SMTP
id <20061004163139b1200eq2t6e>; Wed, 4 Oct 2006 16:31:39 +0000
From: Len Brown <len.brown@intel.com>
To: lenb@kernel.org
Cc: Len Brown <len.brown@intel.com>
Subject: [PATCH 1/14] test: create junk
Date: Wed, 4 Oct 2006 12:34:51 -0400
Message-Id: <11599796921715-git-send-email-len.brown@intel.com>
X-Mailer: git-send-email 1.4.2.3.g128e
In-Reply-To: <11599796913223-git-send-email-len.brown@intel.com>
References: <11599796913223-git-send-email-len.brown@intel.com>
X-Virus-Scanned: ClamAV 0.88.4/1997/Wed Oct 4 15:20:43 2006 on hera.kernel.org
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,
FORGED_RCVD_HELO autolearn=ham version=3.1.3
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on hera.kernel.org
Status: R
X-Status: NGC
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:
Signed-off-by: Len Brown <len.brown@intel.com>
---
junk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/junk b/junk
new file mode 100644
index 0000000..9ecf3cf
--- /dev/null
+++ b/junk
@@ -0,0 +1 @@
+this
--
1.4.2.3.g128e
Same thing happens if I use the SMTP server inside Intel.
I haven't figured out how to send directly via kernel.org using this command
kmail uses a password and ssh to talk to kernel.org.
This is actually sort of an issue too, because smtp.comcast.net
limits the number of messages sent per connection and
will drop after 10 messages with this:
requested action aborted: too many messages on a single connection
thanks,
-Len
^ permalink raw reply related
* asciidoc 7--8 compatibility (was Re: pull-fetch-param.txt)
From: Stefan Richter @ 2006-10-04 16:40 UTC (permalink / raw)
To: Stuart Rackham; +Cc: Junio C Hamano, git
In-Reply-To: <4522E66B.4080103@methods.co.nz>
Stuart Rackham wrote:
> From the AsciiDoc User Guide
> (http://www.methods.co.nz/asciidoc/userguide.html#X53):
>
> If you want to disable unconstrained quotes, the new alternative
> constrained quotes syntax and the new index entry syntax then you can
> define the attribute asciidoc7compatible (for example by using the -a
> asciidoc7compatible command-line option).
Stuart,
the actual issues were:
1.) Input which works with asciidoc 7 fails to build with asciidoc 8
(after the intermediary XML step). This pair of tildes broke (but other
occurences of tilde did not):
| * A suffix '~<n>' to a revision parameter means the commit
| object that is the <n>th generation grand-parent of the named
| commit object, following only the first parent. I.e. rev~3 is
2.) Asciidoc 8 silently swallows characters from input which works with
asciidoc 7. The two pluses in the following line vanished (but instances
of single pluses per input line did not vanish):
| `+?<src>:<dst>`; that is, an optional plus `+`, followed
I wonder:
- Are tilde and plus new special characters in asciidoc 8, or were they
already special characters in asciidoc 7?
[ A pair of single pluses encloses monospaced text in asciidoc 8.
A pair of single tildes encloses subscripts. ]
- If they were already special characters in asciidoc 7, what is the
canonical way to escape them in asciidoc 7, 8, and hopefully 9?
[ If they weren't special characters in asciidoc 7, then we need
to use the asciidoc7compatible attribute. ]
- Does asciidoc 7 accept the asciidoc7compatible attribute?
Thanks.
PS:
Junio, Stuart, here is another inconsistency between asciidoc 7 and 8.
Please have a look at
http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html .
See the ASCII art above "SPECIFYING RANGES". The input
\ | / \
\ | / |
produced
\ | / \ | / |
I.e. backslash-newline was interpreted by asciidoc 7 (or whatever you
use to generate what is put online) as an escaped thus swallowed
newline. But the output that I got here from asciidoc 8 (manpage as well
as the html file) still has backslash and newline printed out.
--
Stefan Richter
-=====-=-==- =-=- --=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: pull-fetch-param.txt
From: Stefan Richter @ 2006-10-04 16:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, srackham
In-Reply-To: <7v64f1np8i.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
...
>> I.e. the first and second + were swallowed, but not the third one.
...
> Without looking at asciidoc 8.0 source, my guess is that it
> treats _anything_ that has two pluses on the same input line as
> quoted by some magical '+'-pair quote. Can you try
> reformatting the original
>
>> <refspec>::
>> The canonical format of a <refspec> parameter is
>> `+?<src>:<dst>`; that is, an optional plus `+`, followed
>> by the source ref, followed by a colon `:`, followed by
>> the destination ref.
>
> to something like
>
>> <refspec>::
>> The canonical format of a <refspec> parameter is
>> `+?<src>:<dst>`; that is, an optional plus
>> `+`, followed
>> by the source ref, followed by a colon `:`, followed by
>> the destination ref.
>
> and verify that conjecture?
This hack does not help. The two `+` are still absent from the manpage
(but as before, the `+` in the next paragraph is printed as desired).
--
Stefan Richter
-=====-=-==- =-=- --=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Luben Tuikov @ 2006-10-04 15:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsli4jy8o.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> (1) grouping clue comes solely from the zebra shading;
> placement of commit-8 does not have anything to do with the
> grouping. It was just that the old interface had N
> commit-8 links for a group that consists of N lines. I
> made it to approximately N/20 links, and you are in favor
> of having 1 link per group.
Yes, either 1 or infinity is fine with me.
> (2) commit-8 is the only visually obviously clickable thing to
> get to the commit. Having them only on the first line in
> the group means for a large group it would scroll off the
> top after reading all the lines in the group through to
> decide it is worth inspecting; think of a case where one
> commit added 80 lines of code and each line is shown in
> 14-dot high font on 1024x768 display which would give you
> 50 lines or so at most.
Yes, I completely understand the problem you're describing
here and have seen even more extreme examples of it.
Consider the general common case where files have had
commits since the initital commit and have various blocks-per-commit.
The eye gets accomodated to seeing one leading commit-8 _per commit block_.
All of a sudden now, it would also see "leading" commit-8
every arbitrary-N rows, leading the brain to believe that this
is a commit-block, while it is not.
This breaks this learned assumption, and makes it confusing
if this is a block-commit or if it is the _previous_ commit.
> Put it another way, it is a redundancy just like the same set of
> links people place at the top and the bottom of a page. It is
> redundant in the sense that you can always scroll to either one,
> but having closer to the mouse pointer helps accessing them. It
I use PgUp in this case.
> > The middle ground as it seems to me, neither infinity nor 1, is
> > to just use the block-per-commit-coloring and use your idea of printing
> > the commit-8 only on the leading block row with mouse-over author
> > and date info. That's an excellent idea.*
>
> I am not quite sure what you mean by this.
Well, you introduced this paramenter N to decide how large the
limit is where one needs to print another redundant commit-8. Yes?
Analyse N and its impact on output:
1) N approaches infinity (extreme case)
2) N = 1 (extreme case)
3) N = something in between (20 is what you had selected)
1) When N approaces infinity, we get the behaviour that there is
no redunant printing of the commit-8 every N rows, since one cannot
have infinite rows. (i.e. N doesn't equal any positive integer)
The commit-8 is printed only on the first row of the commit-block.
2) When N is set to 1, we get the old behaviour, where the same
commit-8 is printed on every line of the commit-block. The redundancy
is of order the number of rows of the commit-block. The extremes
are:
i) Same commit-8 on every line of the file, meaning there were no
commits since the inital commit.
ii) Every line was touched by a commit which didn't touch any
other line. Every line has a different commit.
In both extremes we get a commit-8 per line.
3) Set N to some integer, 1 < N. The question is what should that
integer be?
That's a very interesting question.
Suppose you set N to some positive integer k > 1.
WLG, consider a text file of at least 4*k lines, with 3 commits,
such that commit 1 touches lines 0 to k-1, commit 2 touches
lines k to 3*k-1, and commit 3 touches lines 3k to 4*k-1.
Here is a picture, wlg:
1 : line 0
...
line k-1
2 : line k
...
line 2k-1
2 : line 2k
...
line 3k-1
3: line 3k
...
line 4k-1
Notice that commit 2 is printed at line 2k as well as line k.
This is inconsistent with the assumption that a leading
commit-8 is different than the previous one, and introduces
a new commit-block.
That is, there is no good arbitration for N other than 1 or
infinity, such that the brain doesn't need to break the assumption
that a leading commit introduces a block of different commit than
the previous. And this is indeed what the "zebra" coloring is all
about.
The more extreme case is where you'd have a very large file with
many large commits touching an integer line of lines multiple of k,
such that the smallest commit-block is at least 2k lines.
Then you'd get this confusing patchwork of zebra coloring and in
each block you'd get at least two commit-8 which are the same,
confusing if it is different than the previous or not, since
commit-8s appear at least every k lines.
All I'm saying is that I'd rather keep the leading commit-8 consistent
with the "zebra" coloring.
Luben
^ permalink raw reply
* activestate perl: Makemaker generates broken Makefiles.
From: Alex Riesen @ 2006-10-04 11:25 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 132 bytes --]
Just a heads up. Makefile.PL can't be used. The attached patch removes
everything perl (sorry, but it'd help someone to get going).
[-- Attachment #2: disable-git.xs.patch --]
[-- Type: text/x-diff, Size: 1639 bytes --]
commit bb0ea66746c764f665fc2c5a0f0c289fbbc7eb03
Author: Alex Riesen <raa.lkml@gmail.com>
Date: Wed Oct 4 11:51:51 2006 +0200
remove Git.xs
diff --git a/Makefile b/Makefile
index ee3bc72..93f93e1 100644
--- a/Makefile
+++ b/Makefile
@@ -590,8 +590,7 @@ ### Build rules
all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
-all: perl/Makefile
- $(MAKE) -C perl
+all:
$(MAKE) -C templates
strip: $(PROGRAMS) git$X
@@ -625,15 +624,11 @@ common-cmds.h: Documentation/git-*.txt
chmod +x $@+
mv $@+ $@
-$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
- INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e ' h' \
- -e ' s=.*=use lib (split(/:/, $$ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
- -e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
@@ -766,10 +761,6 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare
rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
-perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
- (cd perl && $(PERL_PATH) Makefile.PL \
- PREFIX='$(prefix_SQ)')
-
doc:
$(MAKE) -C Documentation all
@@ -832,7 +823,6 @@ install: all
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X gitk '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
- $(MAKE) -C perl install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
^ permalink raw reply related
* Re: [PATCH 0/3] gitweb: blame: print commit8 on the leading row of a commit-block
From: Junio C Hamano @ 2006-10-04 8:18 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061004071041.60663.qmail@web31807.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> The following set of patches implements Junio's excellent
> idea of printing the commit-8 only on the leading row of
> a commit block, as well as implementing mouse-over title of
> the author and the date of the commit.
By the way, by definition any idea by me on UI is sucky, not
excellent.
I think this patch gives title= only to rows that happen to be
at the beginning of a block, as opposed to what I placed in
"next" which does it for the whole commit-8 column (and I did
not have to do that for N lines because it uses rowspan to
extend that column over multiple rows), so I suspect it makes
"mouse-over" less useful.
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: gitweb.perl: mode change 0755->0644
From: Junio C Hamano @ 2006-10-04 8:14 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git, Luben Tuikov
In-Reply-To: <20061004074658.GA29964@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> wrote:
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> old mode 100755
> What is the reason to do this? gitweb.perl is a valid perl script and
> can be executed without modification (setting environment variables
> makes this useful).
I made an mistake to make it non-executable in "next", and Luben
is just mimicking my previous typo. Will fix to make it
executable again.
Sorry about the confusion.
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Junio C Hamano @ 2006-10-04 8:12 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061004024837.4462.qmail@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> It is not that I don't like it. For example if we didn't have
> the block-per-commit-coloring, then we'd make use of this, but it
> seems that the block-per-commit-coloring exists for the purpose to
> show conglomerations of same-commit lines, thus obviating the need
> to repeat it (commit-8) every so many lines.
>
> The other question is how many lines should the repeat-chunk be?
>
> In my case I'd like to set it to infinity, since the
> block-per-commit-coloring gives me the same information.
Not that I particularly care that deeply, but my intention was:
(0) having commit-8 on every line was distracting;
(1) grouping clue comes solely from the zebra shading;
placement of commit-8 does not have anything to do with the
grouping. It was just that the old interface had N
commit-8 links for a group that consists of N lines. I
made it to approximately N/20 links, and you are in favor
of having 1 link per group.
(2) commit-8 is the only visually obviously clickable thing to
get to the commit. Having them only on the first line in
the group means for a large group it would scroll off the
top after reading all the lines in the group through to
decide it is worth inspecting; think of a case where one
commit added 80 lines of code and each line is shown in
14-dot high font on 1024x768 display which would give you
50 lines or so at most.
View blame output of README from git.git and scoll down to
around line 400 to see what I mean, with an window that is
around 30 lines. Jon's ASCII art extends for about 40 lines or
so.
Put it another way, it is a redundancy just like the same set of
links people place at the top and the bottom of a page. It is
redundant in the sense that you can always scroll to either one,
but having closer to the mouse pointer helps accessing them. It
is different from the other redundancy we love to hate ;-) that
the shortlog page had -- commit link and the clickable commit
title were immediately next to each other and there was no
argument for that redundancy from accessibility point of view
(the argument was purely "is the clickable commit title obvious
enough?").
> The middle ground as it seems to me, neither infinity nor 1, is
> to just use the block-per-commit-coloring and use your idea of printing
> the commit-8 only on the leading block row with mouse-over author
> and date info. That's an excellent idea.*
I am not quite sure what you mean by this.
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: gitweb.perl: mode change 0755->0644
From: Matthias Lederhofer @ 2006-10-04 7:46 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061004071414.88341.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> old mode 100755
What is the reason to do this? gitweb.perl is a valid perl script and
can be executed without modification (setting environment variables
makes this useful).
^ permalink raw reply
* [PATCH 3/3] gitweb: gitweb.perl: mode change 0755->0644
From: Luben Tuikov @ 2006-10-04 7:14 UTC (permalink / raw)
To: git
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
0 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
old mode 100755
new mode 100644
--
1.4.2.1.ga68d6
^ permalink raw reply
* Re: [PATCH] git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.
From: Junio C Hamano @ 2006-10-04 7:13 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Robert Shearman
In-Reply-To: <20061004065943.GT2871@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> but perhaps we should use the same command line options as pull:
> default to show the diffstat and use -n to suppress it?
I suspect that if your workflow is based on rebase, you usually
fetch and rebase often enough to know what you are rebasing onto
(the fact that this patch did not appear for a long time in
rebase's existence is what makes me think so). So I think not
showing diffstat is probably a sane default.
Opinions?
^ permalink raw reply
* [PATCH 2/3] gitweb: blame: Mouse-over commit-8 shows author and date
From: Luben Tuikov @ 2006-10-04 7:13 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1908141687-p2.txt --]
[-- Type: text/inline; name="p2.txt", Size: 995 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9518086..cba0840 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2496,11 +2496,9 @@ sub git_blame2 {
<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
while (<$fd>) {
- /^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
- my $full_rev = $1;
+ my ($full_rev, $author, $date, $lineno, $data) =
+ /^([0-9a-f]{40}).*?\s\((.*?)\s+([-\d]+ [:\d]+ [-+\d]+)\s+(\d+)\)\s(.*)/;
my $rev = substr($full_rev, 0, 8);
- my $lineno = $2;
- my $data = $3;
my $print_c8 = 0;
if (!defined $last_rev) {
@@ -2512,7 +2510,11 @@ HTML
$print_c8 = 1;
}
print "<tr class=\"$rev_color[$current_color]\">\n";
- print "<td class=\"sha1\">";
+ print "<td class=\"sha1\"";
+ if ($print_c8 == 1) {
+ print " title=\"$author, $date\"";
+ }
+ print ">";
if ($print_c8 == 1) {
print $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
esc_html($rev));
--
1.4.2.1.ga68d6
^ permalink raw reply related
* [PATCH 1/3] gitweb: blame: print commit-8 on the leading row of a commit-block
From: Luben Tuikov @ 2006-10-04 7:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
Print commit-8 only on the first, leading row of
a commit block, to complement the per-commit block coloring.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/inline; name="p1.txt", Size: 1113 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a9e95c9..9518086 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2501,17 +2501,23 @@ HTML
my $rev = substr($full_rev, 0, 8);
my $lineno = $2;
my $data = $3;
+ my $print_c8 = 0;
if (!defined $last_rev) {
$last_rev = $full_rev;
+ $print_c8 = 1;
} elsif ($last_rev ne $full_rev) {
$last_rev = $full_rev;
$current_color = ++$current_color % $num_colors;
+ $print_c8 = 1;
}
print "<tr class=\"$rev_color[$current_color]\">\n";
- print "<td class=\"sha1\">" .
- $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
- esc_html($rev)) . "</td>\n";
+ print "<td class=\"sha1\">";
+ if ($print_c8 == 1) {
+ print $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
+ esc_html($rev));
+ }
+ print "</td>\n";
print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
esc_html($lineno) . "</a></td>\n";
print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
--
1.4.2.1.ga68d6
^ permalink raw reply related
* [PATCH 0/3] gitweb: blame: print commit8 on the leading row of a commit-block
From: Luben Tuikov @ 2006-10-04 7:10 UTC (permalink / raw)
To: git
The following set of patches implements Junio's excellent
idea of printing the commit-8 only on the leading row of
a commit block, as well as implementing mouse-over title of
the author and the date of the commit. Thus making the output
of git_blame2() less cluttered yet able to give more information
should the user mouse-over the commit.
The difference is that this implementations doesn't use a "stack-like"
chunk to represent each block-per-commit, thus eliminating the concern
of rare but present files with 100s of 1000s of lines with only an
initial commit.
Luben
^ permalink raw reply
* Re: [PATCH] git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.
From: Martin Waitz @ 2006-10-04 6:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Shearman, git
In-Reply-To: <7v4pulm3j6.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 915 bytes --]
hoi :)
On Tue, Oct 03, 2006 at 03:35:09PM -0700, Junio C Hamano wrote:
> Robert Shearman <rob@codeweavers.com> writes:
> > +-v, \--verbose::
> > + Display a diffstat of what changed upstream since the last rebase.
> > +
>
> I initially was a bit surprised that you did not show diff
> between onto and our HEAD (i.e. show the damages contained in
> the topic you are rebasing that will be inflicted on upstream),
> but I think your way of showing the upstream changes makes more
> sense. From the workflow point of view, this is for people who
> rebase instead of pull, and when pulling we show what the
> upstream did while we were looking the other way, so this
> naturally matches that behaviour for rebase. I would say it is
> a good thinking.
but perhaps we should use the same command line options as pull:
default to show the diffstat and use -n to suppress it?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Jakub Narebski @ 2006-10-04 3:07 UTC (permalink / raw)
To: git
In-Reply-To: <20061004024837.4462.qmail@web31808.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> > I like the fact that the "data part" of blame is text, and
>> > that the commit-8 is on the left, and color-chunked. Sometimes
>> > people simply _remember_ a number of commit-8's and thus the
>> > layout of blame is intentional, since they can look to the left
>> > and recognize a commit-8...
>>
>> It is not only the initial commit. A substantial rewrite and
>> new development also has the same issue.
>>
>> I think you are also contradicting yourself by saying that
>> people would recognize a commit-8, and at the same time you do
>> not like the chunk code that makes sure you do not get too few
>> of them. If people _do_ recognize commit-8 (I seriously doubt
>> that), then wouldn't it help to make sure you have them on every
>> couple-dozen lines so that the user would see the familiar one
>> even when scrolled?
>
> It is not that I don't like it. For example if we didn't have
> the block-per-commit-coloring, then we'd make use of this, but it
> seems that the block-per-commit-coloring exists for the purpose to
> show conglomerations of same-commit lines, thus obviating the need
> to repeat it (commit-8) every so many lines.
Colors repeat. They are not enough.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Luben Tuikov @ 2006-10-04 2:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Waitz
In-Reply-To: <7virj0lsua.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> > I like the fact that the "data part" of blame is text, and
> > that the commit-8 is on the left, and color-chunked. Sometimes
> > people simply _remember_ a number of commit-8's and thus the
> > layout of blame is intentional, since they can look to the left
> > and recognize a commit-8...
>
> It is not only the initial commit. A substantial rewrite and
> new development also has the same issue.
>
> I think you are also contradicting yourself by saying that
> people would recognize a commit-8, and at the same time you do
> not like the chunk code that makes sure you do not get too few
> of them. If people _do_ recognize commit-8 (I seriously doubt
> that), then wouldn't it help to make sure you have them on every
> couple-dozen lines so that the user would see the familiar one
> even when scrolled?
It is not that I don't like it. For example if we didn't have
the block-per-commit-coloring, then we'd make use of this, but it
seems that the block-per-commit-coloring exists for the purpose to
show conglomerations of same-commit lines, thus obviating the need
to repeat it (commit-8) every so many lines.
The other question is how many lines should the repeat-chunk be?
In my case I'd like to set it to infinity, since the
block-per-commit-coloring gives me the same information.
The other extreme case is set it to 1, thus obviating the need to
use block-per-commit-coloring.
The middle ground as it seems to me, neither infinity nor 1, is
to just use the block-per-commit-coloring and use your idea of printing
the commit-8 only on the leading block row with mouse-over author
and date info. That's an excellent idea.*
Luben
* I've three patches which implement your excellent idea but without
using a "stack-like" chunk, eliminating the concern of rare but present
files with 100s of 1000s of lines with only an initial commit. Should I
post them?
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Junio C Hamano @ 2006-10-04 2:26 UTC (permalink / raw)
To: ltuikov; +Cc: git, Martin Waitz
In-Reply-To: <20061003194551.70537.qmail@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> Then you don't need to worry about repeating the commit id,
>> and perhaps it is not even needed any more?
I am contradicting myself but I personally like what Pasky runs
at http://repo.or.cz/ too, although it goes to the other extreme
to spend more space for line-by-line annotation ;-)
> I like Junio's first patch on the subject with the only
> objection that the "chunk" can be 100s of 1000s of lines
> if the file is too big and there had never been any changes
> since the initial commit.
>
> I like the fact that the "data part" of blame is text, and
> that the commit-8 is on the left, and color-chunked. Sometimes
> people simply _remember_ a number of commit-8's and thus the
> layout of blame is intentional, since they can look to the left
> and recognize a commit-8...
It is not only the initial commit. A substantial rewrite and
new development also has the same issue.
I think you are also contradicting yourself by saying that
people would recognize a commit-8, and at the same time you do
not like the chunk code that makes sure you do not get too few
of them. If people _do_ recognize commit-8 (I seriously doubt
that), then wouldn't it help to make sure you have them on every
couple-dozen lines so that the user would see the familiar one
even when scrolled?
^ permalink raw reply
* Re: pull-fetch-param.txt
From: Junio C Hamano @ 2006-10-04 2:03 UTC (permalink / raw)
To: Stuart Rackham; +Cc: git, Stefan Richter
In-Reply-To: <4522E66B.4080103@methods.co.nz>
Stuart Rackham <srackham@methods.co.nz> writes:
> From the AsciiDoc User Guide
> (http://www.methods.co.nz/asciidoc/userguide.html#X53):
>
> If you want to disable unconstrained quotes, the new alternative
> constrained quotes syntax and the new index entry syntax then you can
> define the attribute asciidoc7compatible (for example by using the -a
> asciidoc7compatible command-line option).
>
> --
> Stuart Rackham
Thank you for a quick reply.
Stefan, can you try it with the earlier commit to escape tilde
reverted and see if our documentation set behaves well?
^ 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