* 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
* Re: pull-fetch-param.txt
From: Stuart Rackham @ 2006-10-03 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Richter, git
In-Reply-To: <7v64f1np8i.fsf@assigned-by-dhcp.cox.net>
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
Junio C Hamano wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
>
>> Junio C Hamano wrote:
>>> It's a bit sad that asciidoc's nicer quoting features
>>> are not backward compatible.
>> Yes, this is awkward. Here comes the next candidate for quoting.
>
> [Stuart Rackham CC'ed]
>
> At this point I have to say
>
> What the h*ck AsciiDoc people are thinking?
>
> Heck, I thought we were one of the more important customers of
> asciidoc project and not breaking us meant at least something to
> them; our name is at the top of "Project using AsciiDoc" section
> of their website, http:/www.methods.co.nz/asciidoc/. Apparently
> I was delusional.
>
> Introducing nicer new features is a good thing, but you do not
> break existing documents without a good reason and an escape
> hatch.
>
> Put it more mildly, I think we need to find out what their
> policy on backward compatibility is, and if it is "screw it --
> you should re-mark-up your documents to match the newer rule
> every time we have a new release. By the way, you always have
> the option to stay at older releases of ours", then we should
> seriously consider switching the documentation format to
> something else. I honestly hope it does not have to come to
> that.
>
>> In pull-fetch-param.txt:
>>
>> ----8<----
>> <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.
>> +
>> The remote ref that matches <src>
>> is fetched, and if <dst> is not empty string, the local
>> ref that matches it is fast forwarded using <src>.
>> Again, if the optional plus `+` is used, the local ref
>> ---->8----
>>
>> "man git-fetch" and "man git-pull" show:
>> ----8<----
>> <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.
>>
>> The remote ref that matches <src> is fetched, and if <dst> is
>> not empty string, the local ref that matches it is fast for-
>> warded using <src>. Again, if the optional plus + is used, the
>> ---->8----
>>
>> I.e. the first and second + were swallowed, but not the third one.
>> This is the fix for asciidoc 8.0.0:
>> `$$+$$?<src>:<dst>`; that is, an optional plus `+`, followed
>
> 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?
>
> We already had to deal with this with your patch for tilde.
> Arguably tilde and caret are rare enough in plain text so we can
> live with having to spell it as {caret} and {tilde}, but if my
> guess is correct, that means we have to spell plus '+' as {plus}
> with an appropriate entry in asciidoc.conf (or "\+" if it works
> in both older and newer versions). As more ordinary characters
> are taken for special mark-up purposes, we would need to keep
> adding them to our list. Where does the madness end?
>
> Fortunately AsciiDoc 8.0 is still young. Maybe they can find a
> fix for this in a way that does not break documents written for
> (at least recent versions of) AsciiDoc 7; it might have to break
> documents written for early betas and the initial release of
> 8.0, but that is _much_ better than breaking existing documents,
> in my extremely biased opinion as a very unhappy user.
>
^ 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-03 22:35 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <45228FEB.10602@codeweavers.com>
Robert Shearman <rob@codeweavers.com> writes:
> Signed-off-by: Robert Shearman <rob@codeweavers.com>
> @@ -121,6 +121,9 @@ OPTIONS
> is used instead (`git-merge-recursive` when merging a single
> head, `git-merge-octopus` otherwise). This implies --merge.
>
> +-v, \--verbose::
> + Display a diffstat of what changed upstream since the last rebase.
> +
> include::merge-strategies.txt[]
>
> NOTES
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.
^ permalink raw reply
* [PATCH] Update the gitweb/README file to include setting the GITWEB_CONFIG environment
From: Alan Chandler @ 2006-10-03 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alan Chandler
From: Alan Chandler <alan@chandlerfamily.org.uk>
Signed-off-by: Alan Chandler <alan@chandlerfamily.org.uk>
---
gitweb/README | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 61c7ab5..099cfae 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -43,6 +43,7 @@ repositories, you can configure apache l
DocumentRoot /pub/git
RewriteEngine on
RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
+ SetEnv GITWEB_CONFIG /etc/gitweb.conf
</VirtualHost>
The above configuration expects your public repositories to live under
@@ -51,6 +52,12 @@ both as cloneable GIT URL and as browsea
If you then start your git-daemon with --base-path=/pub/git --export-all
then you can even use the git:// URL with exactly the same path.
+Setting the environment variable GITWEB_CONFIG will tell gitweb to use
+the named file (ie in this example /etc/gitweb.conf) as a
+configuration for gitweb. Perl variables defined in here will
+override the defaults given at the head of the gitweb.perl (or
+gitweb.cgi). Look at the comments in that file for information on
+which variables and what they mean.
Originally written by:
--
1.4.2.1
^ permalink raw reply related
* Re: [StGIT PATCH 0/2] Some StGit improvement
From: Robin Rosenberg @ 2006-10-03 21:37 UTC (permalink / raw)
To: git
In-Reply-To: <20061003213025.8F18028AF4@lathund.dewire.com>
This demonstrates the usability issue, I think :/
-- robin
^ permalink raw reply
* [StGIT PATCH 2/3] Add an optional prefix to the PATCH subject when mailing.
From: Robin Rosenberg @ 2006-10-03 21:34 UTC (permalink / raw)
To: git
In-Reply-To: <20061003213453.26195.54830.stgit@lathund.dewire.com>
From: Robin Rosenberg <robin.rosenberg@dewire.com>
This is for submitting patches to mailing lists with multiple
projects.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
stgit/commands/mail.py | 15 +++++++++++++++
templates/covermail.tmpl | 2 +-
templates/patchmail.tmpl | 2 +-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index bd56f16..8a713a1 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -65,6 +65,7 @@ the following variables:
%(diffstat)s - diff statistics
%(date)s - current date/time
%(version)s - ' version' string passed on the command line (or empty)
+ %(prefix)s - prefix the subject lines's "PATCH" with this
%(patchnr)s - patch number
%(totalnr)s - total number of patches to be sent
%(number)s - empty if only one patch is sent or ' patchnr/totalnr'
@@ -95,6 +96,8 @@ options = [make_option('-a', '--all',
action = 'store_true'),
make_option('-v', '--version', metavar = 'VERSION',
help = 'add VERSION to the [PATCH ...] prefix'),
+ make_option('--prefix', metavar = 'PREFIX',
+ help = 'add PREFIX to the [...PATCH ...] prefix'),
make_option('-t', '--template', metavar = 'FILE',
help = 'use FILE as the message template'),
make_option('-c', '--cover', metavar = 'FILE',
@@ -232,6 +235,11 @@ def __build_cover(tmpl, total_nr, msg_id
else:
version_str = ''
+ if options.prefix:
+ prefix_str = options.prefix + ' '
+ else:
+ prefix_str = ''
+
total_nr_str = str(total_nr)
patch_nr_str = '0'.zfill(len(total_nr_str))
if total_nr > 1:
@@ -243,6 +251,7 @@ def __build_cover(tmpl, total_nr, msg_id
'endofheaders': headers_end,
'date': email.Utils.formatdate(localtime = True),
'version': version_str,
+ 'prefix': prefix_str,
'patchnr': patch_nr_str,
'totalnr': total_nr_str,
'number': number_str}
@@ -312,6 +321,11 @@ def __build_message(tmpl, patch, patch_n
else:
version_str = ''
+ if options.prefix:
+ prefix_str = options.prefix + ' '
+ else:
+ prefix_str = ''
+
total_nr_str = str(total_nr)
patch_nr_str = str(patch_nr).zfill(len(total_nr_str))
if total_nr > 1:
@@ -330,6 +344,7 @@ def __build_message(tmpl, patch, patch_n
rev2 = git_id('%s//top' % patch)),
'date': email.Utils.formatdate(localtime = True),
'version': version_str,
+ 'prefix': prefix_str,
'patchnr': patch_nr_str,
'totalnr': total_nr_str,
'number': number_str,
diff --git a/templates/covermail.tmpl b/templates/covermail.tmpl
index 44cd19e..ba1dd9d 100644
--- a/templates/covermail.tmpl
+++ b/templates/covermail.tmpl
@@ -1,5 +1,5 @@
From: %(maintainer)s
-Subject: [PATCH%(version)s%(number)s] Series short description
+Subject: [%(prefix)sPATCH%(version)s%(number)s] Series short description
Date: %(date)s
%(endofheaders)s
The following series implements...
diff --git a/templates/patchmail.tmpl b/templates/patchmail.tmpl
index 7881993..b0df904 100644
--- a/templates/patchmail.tmpl
+++ b/templates/patchmail.tmpl
@@ -1,5 +1,5 @@
From: %(maintainer)s
-Subject: [PATCH%(version)s%(number)s] %(shortdescr)s
+Subject: [%(prefix)sPATCH%(version)s%(number)s] %(shortdescr)s
Date: %(date)s
%(endofheaders)s
From: %(authname)s <%(authemail)s>
^ permalink raw reply related
* [StGIT PATCH 1/3] Command to move a patch to the top
From: Robin Rosenberg @ 2006-10-03 21:34 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
---
stgit/main.py | 3 +++
t/t1500-float.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/stgit/main.py b/stgit/main.py
index f59bce6..e9cc6cd 100644
--- a/stgit/main.py
+++ b/stgit/main.py
@@ -38,6 +38,7 @@ import stgit.commands.clone
import stgit.commands.commit
import stgit.commands.export
import stgit.commands.files
+import stgit.commands.float
import stgit.commands.fold
import stgit.commands.goto
import stgit.commands.id
@@ -77,6 +78,7 @@ commands = {
'commit': stgit.commands.commit,
'export': stgit.commands.export,
'files': stgit.commands.files,
+ 'float': stgit.commands.float,
'fold': stgit.commands.fold,
'goto': stgit.commands.goto,
'id': stgit.commands.id,
@@ -113,6 +115,7 @@ stackcommands = (
'applied',
'clean',
'commit',
+ 'float',
'goto',
'init',
'pop',
diff --git a/t/t1500-float.sh b/t/t1500-float.sh
new file mode 100755
index 0000000..670050f
--- /dev/null
+++ b/t/t1500-float.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Robin Rosenberg
+#
+
+test_description='Test floating a number of patches to the top of the stack
+
+'
+
+. ./test-lib.sh
+
+test_expect_success \
+ 'Initialize the StGIT repository' \
+ 'stg init &&
+ stg new A -m "a" && echo A >a.txt && stg add a.txt && stg refresh &&
+ stg new B -m "b" && echo B >b.txt && stg add b.txt && stg refresh &&
+ stg new C -m "c" && echo C >c.txt && stg add c.txt && stg refresh &&
+ stg new D -m "d" && echo D >d.txt && stg add d.txt && stg refresh &&
+ stg new E -m "e" && echo E >e.txt && stg add e.txt && stg refresh &&
+ stg new F -m "f" && echo F >f.txt && stg add f.txt && stg refresh &&
+ test "`echo \`cat .git/patches/master/applied\``" = "A B C D E F"
+ '
+
+test_expect_success \
+ 'Float A to top' \
+ 'stg float A &&
+ test "`echo \`cat .git/patches/master/applied\``" = "B C D E F A"
+ '
+test_expect_success \
+ 'Float A to top (noop)' \
+ 'stg float A &&
+ test "`echo \`cat .git/patches/master/applied\``" = "B C D E F A"
+ '
+test_expect_success \
+ 'Float B C to top (noop)' \
+ 'stg float B C &&
+ test "`echo \`cat .git/patches/master/applied\``" = "D E F A B C"
+ '
+test_expect_success \
+ 'Float E A to top (noop)' \
+ 'stg float E A &&
+ test "`echo \`cat .git/patches/master/applied\``" = "D F B C E A"
+ '
+test_done
^ permalink raw reply related
* [StGIT PATCH 3/3] Fix the --cover option.
From: Robin Rosenberg @ 2006-10-03 21:34 UTC (permalink / raw)
To: git
In-Reply-To: <20061003213453.26195.54830.stgit@lathund.dewire.com>
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
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 8a713a1..c7f0f46 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -419,7 +419,7 @@ def func(parser, options, args):
if options.cover or options.edit:
# find the template file
if options.cover:
- tmpl = file(options.template).read()
+ tmpl = file(options.cover).read()
else:
tmpl = templates.get_template('covermail.tmpl')
if not tmpl:
^ permalink raw reply related
* [StGIT PATCH 0/2] Some StGit improvement
From: Robin Rosenberg @ 2006-10-03 21:07 UTC (permalink / raw)
To: git
Here are some small improvements I made to the wonderful StGIT.
The first one is a new command to do the popping and pushing
necessary to float a patch to the top of the stack.
The second is a small improvement to change the [PATCH] prefix
to identify what the patch is for. In this case StGIT.
The third one makes the --cover work. There are some usability
issues with --cover, but at least it works now.
-- robin
^ permalink raw reply
* Re: "git diff --summary --diff-filter=AD" without --stat does not work.
From: Junio C Hamano @ 2006-10-03 20:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610032221330.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I think it should only show create/delete notes and not even
>> diff text.
>
> What exactly is the problem? My tree only has minor patches, which should
> not affect the output of your command, and it does this:
>
> $ git diff --summary --diff-filter=AD next..pu
> create mode 100644 builtin-diff-status.c
> create mode 100644 para-walk.c
> create mode 100644 para-walk.h
> create mode 100644 test-para.c
I suspect the real issue is that it does not turn 'recursive'
on.
^ permalink raw reply
* Re: [PATCH] gitweb: start to generate PATH_INFO URLs.
From: Martin Waitz @ 2006-10-03 20:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <efu7r9$fra$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
hoi :-)
On Tue, Oct 03, 2006 at 07:50:00PM +0200, Jakub Narebski wrote:
> Perhaps we should not add 'override' key, and test for existence
> of 'override' to fallback on 'sub'.
this is a no-op: if the config file sets override to 1 then
we still break.
Of course one say: don't do it then.
But then we don't need the check at all.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Check that a tag exists using show-ref instead of looking for the ref file.
From: Junio C Hamano @ 2006-10-03 20:26 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200610032211.05847.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Junio C Hamano wrote:
>> Thanks. We also need this to avoid refetching already packed
>> tags.
>
> Yeah, I did a very quick check on the shell scripts and I obviously missed
> some places that need updates.
>
> In fact, I couldn't resist to start implementing the deleted-refs/$frotz~ref
> stuff we talked about...
How would that help? We need to audit the existing scripts
since they would not look under $GIT_DIR/deleted-refs currently
anyway.
^ permalink raw reply
* Re: "git diff --summary --diff-filter=AD" without --stat does not work.
From: Johannes Schindelin @ 2006-10-03 20:23 UTC (permalink / raw)
To: Junio Hamano; +Cc: junkio, git
In-Reply-To: <7v3ba5tdlj.fsf@dee.twinsun.com>
Hi,
On Tue, 3 Oct 2006, Junio Hamano wrote:
> I think it should only show create/delete notes and not even
> diff text.
What exactly is the problem? My tree only has minor patches, which should
not affect the output of your command, and it does this:
$ git diff --summary --diff-filter=AD next..pu
create mode 100644 builtin-diff-status.c
create mode 100644 para-walk.c
create mode 100644 para-walk.h
create mode 100644 test-para.c
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Luben Tuikov @ 2006-10-03 20:20 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <200610031018.40273.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 3 Oct 2006, Junio C Hamano wrote:
>
> > Honestly, I _hate_ to be in the position to decide in which
> > color the bikeshed should be, but sometimes that is what a
> > maintainer has to do.
>
> Joys and tribulations of being maintainer... ;-)
Junio is doing an excellent job at maintaining GIT! He's
tried to accomodate everyone, since this kind of flexibility
decides how many entities and companies adopt GIT and in return
this makes GIT better, by having those entities and companies
send back patches. It is a well understood loop.
You should take a look at Linux and some subsystem's maintainers
"maintainership". The worst thing by far that can happen to
a project being maintained is when "maintainership" becomes
the maintainer's _job_, as opposed to a professional (specializing
in a contingent field) who is doing maintainership in his spare
time. (i.e. the way it was in the 70s-80s with UNIX.)
Anyway, I digress, sorry.
> > By the same logic, the purpose of the tree view is to show
> > contents of a tree object. If the user picks up the convention
> > for the short log that each listed commit can be clicked to
> > obtain details about it, it probably is natural for the user to
> > expect that each listed entry in the tree view can be clicked to
> > obtain details about it, so not showing the redundant tree/blob
> > link is in line with that. And it would be consistent not to
> > give underline to the file or directory names.
>
> I'd rather have underline for directory names to distinguish
> it even more from files (blob entries), even for monochromatic
> text display.
I strongly agree with Junio. Intuition of gitweb spills in all
of its interfaces. The nature of gitweb dictates that certain
things are clickable, simply because it is, after all, a web
interface to none other but GIT.
We don't need an overly explicit interface in gitweb, since gitweb
is not supposed to _teach_ git, but present it.
Take a look at other SCMs interfaces: perforce, cvs, clearcase, etc.
> I am of two mind about removing "redundant" links movement.
>
> First, I don't thing that avoiding redundancy in _user interface_
> is a good argument. We sometimes add redundancy, for example in
> commitdiff view for each patch we have sha1 of blob in the gitweb
> header clickable, and obvously link, and we have the names of from
> and to files in diff header "hidden links" and clickable. I could
> agree with the argument about removing redundancy from the _code_,
> and/or with the argument about _uncluttering_ interface.
>
> Second, removing "redundant" links coupled with the fact that
> the links the removed links duplicated cannot for mentioned resons
> have default links style, so it is harder to guess that they are
> links ("mystery meat navigation", although not in it's worst edition).
> So there is tradeoff. Uncluttering the interface and simplifying
> the code, but at the cost of gitweb interface being harder to beginners.
What "beginners" are you refering to? GIT beginners or gitweb beginners?
gitweb is not supposed to be a teaching tool to GIT.
> It is a question of policy then, do we cater to beginner users, or to
> advanced users (which know/discovered that file name in tree view
> and commit subject/title line in shortlog are links to respectively
> blob view of a file and commit view of a commit).
>
> Third, we should be consistent: either leave redundant links, perhaps
> separating it by putting it into separate "selflink" column (see for
> example tags view), or remove redundat links where possible in all
> views.
An absolutely excellent argument for the confines of a college course
paper or assignment on GUI. Not very convicing to people with years
and years of experience in SCMs and what-not.
What we want is not some zelous argument about what is the "right"
way or the "proper" way (all very subjective) of doing the interface
of gitweb. What we want is an intuitive and workable interface,
minimizing the number of eye movements, mouse movement, mouse clicks
to get to the information being sought.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: start to generate PATH_INFO URLs.
From: Junio C Hamano @ 2006-10-03 20:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <efu7r9$fra$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Martin Waitz wrote:
>>>
>>>> + 'pathinfo' => {
>>>> + 'override' => 0,
>>>> + 'default' => [1]},
>>>
>>> You should add failsafe to gitweb_check_feature for when 'sub' is not
> set;
>>> for example when somebody sets $feature{'pathinfo'}{'override'} to 1.
>>
>> Yes, I noticed this last night while playing with it. We would
>> at least need a big warning that says this should not be made
>> overridable (which does not make any sense anyway).
>>
>> Setting 'sub' to a failsafe one that only returns what is in the
>> default without looking at individual repository would be the
>> cleanest, I think.
>
> Perhaps we should not add 'override' key, and test for existence
> of 'override' to fallback on 'sub'.
Excellent idea. Please make it so.
^ permalink raw reply
* Re: [PATCH] gitweb: document webserver configuration for common gitweb/repo URLs.
From: Junio C Hamano @ 2006-10-03 20:15 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <E1GUkQe-0007qU-AN@home.chandlerfamily.org.uk>
"Alan Chandler" <alan@chandlerfamily.org.uk> writes:
> Martin Waitz writes:
>
>> Add a small apache configuration which shows how to use apache
>> to put gitweb and GIT repositories at the same URL.
>
> It might be helpful to include
>
> SetEnv GITWEB_CONFIG /etc/gitweb.conf
>
> in that little apache snippet, to show how specify a config file for
> gitweb.
I agree. Please make it so by sending in a one-liner patch with
sign-off so that we can get attribution right without minimum
fuss.
^ permalink raw reply
* [PATCH] Fix usage string to match that given in the man page
From: Alan Chandler @ 2006-10-03 20:11 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
Still not managed to understand git-send-mail sufficiently well to not
accidently miss of this list when I sending it to Junio
Signed-off-by: Alan Chandler <alan@chandlerfamily.org.uk>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index ae80e78..b8e8622 100644
--- a/git.c
+++ b/git.c
@@ -16,7 +16,7 @@ #include "quote.h"
#include "builtin.h"
const char git_usage_string[] =
- "git [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ ARGS ]";
+ "git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate] [--bare]
[--git-dir=GIT_DIR] [--help] COMMAND [ARGS]";
static void prepend_to_path(const char *dir, int len)
{
--
1.4.2.1
-------------------------------------------------------
--
Alan Chandler
http://www.chandlerfamily.org.uk
[-- Attachment #2: [PATCH] Fix usage string to match that given in the man page --]
[-- Type: text/plain, Size: 625 bytes --]
From: Alan Chandler <alan@chandlerfamily.org.uk>
Signed-off-by: Alan Chandler <alan@chandlerfamily.org.uk>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index ae80e78..b8e8622 100644
--- a/git.c
+++ b/git.c
@@ -16,7 +16,7 @@ #include "quote.h"
#include "builtin.h"
const char git_usage_string[] =
- "git [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ ARGS ]";
+ "git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate] [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]";
static void prepend_to_path(const char *dir, int len)
{
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] Check that a tag exists using show-ref instead of looking for the ref file.
From: Christian Couder @ 2006-10-03 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlknxrcja.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Thanks. We also need this to avoid refetching already packed
> tags.
Yeah, I did a very quick check on the shell scripts and I obviously missed
some places that need updates.
In fact, I couldn't resist to start implementing the deleted-refs/$frotz~ref
stuff we talked about...
Christian.
^ permalink raw reply
* Re: pull-fetch-param.txt
From: Junio C Hamano @ 2006-10-03 20:01 UTC (permalink / raw)
To: Stefan Richter; +Cc: git, srackham
In-Reply-To: <45222B18.1090305@s5r6.in-berlin.de>
Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
> Junio C Hamano wrote:
>> It's a bit sad that asciidoc's nicer quoting features
>> are not backward compatible.
>
> Yes, this is awkward. Here comes the next candidate for quoting.
[Stuart Rackham CC'ed]
At this point I have to say
What the h*ck AsciiDoc people are thinking?
Heck, I thought we were one of the more important customers of
asciidoc project and not breaking us meant at least something to
them; our name is at the top of "Project using AsciiDoc" section
of their website, http:/www.methods.co.nz/asciidoc/. Apparently
I was delusional.
Introducing nicer new features is a good thing, but you do not
break existing documents without a good reason and an escape
hatch.
Put it more mildly, I think we need to find out what their
policy on backward compatibility is, and if it is "screw it --
you should re-mark-up your documents to match the newer rule
every time we have a new release. By the way, you always have
the option to stay at older releases of ours", then we should
seriously consider switching the documentation format to
something else. I honestly hope it does not have to come to
that.
> In pull-fetch-param.txt:
>
> ----8<----
> <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.
> +
> The remote ref that matches <src>
> is fetched, and if <dst> is not empty string, the local
> ref that matches it is fast forwarded using <src>.
> Again, if the optional plus `+` is used, the local ref
> ---->8----
>
> "man git-fetch" and "man git-pull" show:
> ----8<----
> <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.
>
> The remote ref that matches <src> is fetched, and if <dst> is
> not empty string, the local ref that matches it is fast for-
> warded using <src>. Again, if the optional plus + is used, the
> ---->8----
>
> I.e. the first and second + were swallowed, but not the third one.
> This is the fix for asciidoc 8.0.0:
> `$$+$$?<src>:<dst>`; that is, an optional plus `+`, followed
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?
We already had to deal with this with your patch for tilde.
Arguably tilde and caret are rare enough in plain text so we can
live with having to spell it as {caret} and {tilde}, but if my
guess is correct, that means we have to spell plus '+' as {plus}
with an appropriate entry in asciidoc.conf (or "\+" if it works
in both older and newer versions). As more ordinary characters
are taken for special mark-up purposes, we would need to keep
adding them to our list. Where does the madness end?
Fortunately AsciiDoc 8.0 is still young. Maybe they can find a
fix for this in a way that does not break documents written for
(at least recent versions of) AsciiDoc 7; it might have to break
documents written for early betas and the initial release of
8.0, but that is _much_ better than breaking existing documents,
in my extremely biased opinion as a very unhappy user.
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Luben Tuikov @ 2006-10-03 19:45 UTC (permalink / raw)
To: Martin Waitz, Junio C Hamano; +Cc: git
In-Reply-To: <20061003192018.GR2871@admingilde.org>
--- Martin Waitz <tali@admingilde.org> wrote:
> hoi :)
>
> On Tue, Oct 03, 2006 at 12:25:45AM -0700, Junio C Hamano wrote:
> > [PATCH] gitweb: make leftmost column of blame less cluttered.
> >
> > Instead of labelling each and every line with clickable commit
> > object name, this makes the blame output to show them only on
> > the first line of each group of lines from the same revision.
> >
> > Also it makes mouse-over to show the minimum authorship and
> > authordate information for extra cuteness ;-).
>
> what about making the line itself clickable and adding the
> mouse-over there, too?
> Then you don't need to worry about repeating the commit id,
> and perhaps it is not even needed any more?
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...
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Martin Waitz @ 2006-10-03 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: ltuikov, git
In-Reply-To: <7vmz8dsvwm.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
hoi :)
On Tue, Oct 03, 2006 at 12:25:45AM -0700, Junio C Hamano wrote:
> [PATCH] gitweb: make leftmost column of blame less cluttered.
>
> Instead of labelling each and every line with clickable commit
> object name, this makes the blame output to show them only on
> the first line of each group of lines from the same revision.
>
> Also it makes mouse-over to show the minimum authorship and
> authordate information for extra cuteness ;-).
what about making the line itself clickable and adding the
mouse-over there, too?
Then you don't need to worry about repeating the commit id,
and perhaps it is not even needed any more?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* "git diff --summary --diff-filter=AD" without --stat does not work.
From: Junio Hamano @ 2006-10-03 19:15 UTC (permalink / raw)
To: junkio; +Cc: git
I think it should only show create/delete notes and not even
diff text.
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Luben Tuikov @ 2006-10-03 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz8dsvwm.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Perhaps like this. This has hardcoded chunk-cap of 20 lines,
> which means we never buffer more than 40 lines and never emit
> more than 20 lines at a time. The reason we do not immediately
> flush after getting 20 lines is if we have a block of 21 lines
> we would end up giving 20 line chunk and 1 line chunk and then a
> chunk for the different revision (orphaned line). In such a
> case we are better off giving two evenly divided chunks and that
> is why we buffer up to twice the chunk-cap size.
>
> If people are interested we probably would want to make 20
> configurable. Maybe not. I personally suspect it does not
> matter much.
I think this would get us into too much "special cases". The colored
chunks of commits were added with the intention of "single commit",
so I think we should be ok, to have a single row at the top for
the initial commit when the file had not been changed since.
Initial commits are normally "well known commits", so I think it should
be ok to not have to print every 20 or so lines as this breaks the
color-block-per-commit intention.
Luben
>
> -- >8 --
> [PATCH] gitweb: make leftmost column of blame less cluttered.
>
> Instead of labelling each and every line with clickable commit
> object name, this makes the blame output to show them only on
> the first line of each group of lines from the same revision.
>
> Also it makes mouse-over to show the minimum authorship and
> authordate information for extra cuteness ;-).
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> gitweb/gitweb.perl | 99 +++++++++++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 86 insertions(+), 13 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> old mode 100755
> new mode 100644
> index 3e9d4a0..55d1b2c
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2430,9 +2430,64 @@ sub git_tag {
> git_footer_html();
> }
>
> +sub git_blame_flush_chunk {
> + my ($name, $revdata, $color, $rev, @line) = @_;
> + my $label = substr($rev, 0, 8);
> + my $line = scalar(@line);
> + my $cnt = 0;
> + my $pop = '';
> +
> + if ($revdata->{$rev} ne '') {
> + $pop = ' title="' . esc_html($revdata->{$rev}) . '"';
> + }
> +
> + for (@line) {
> + my ($lineno, $data) = @$_;
> + $cnt++;
> + print "<tr class=\"$color\">\n";
> + if ($cnt == 1) {
> + print "<td class=\"sha1\"$pop";
> + if ($line > 1) {
> + print " rowspan=\"$line\"";
> + }
> + print ">";
> + print $cgi->a({-href => href(action=>"commit",
> + hash=>$rev,
> + file_name=>$name)},
> + $label);
> + 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";
> + print "</tr>\n";
> + }
> +}
> +
> +# We can have up to N*2 lines. If it is more than N lines, split it
> +# into two to avoid orphans.
> +sub git_blame_flush_chunk_1 {
> + my ($chunk_cap, $name, $revdata, $color, $rev, @chunk) = @_;
> + if ($chunk_cap < @chunk) {
> + my @first = splice(@chunk, 0, @chunk/2);
> + git_blame_flush_chunk($name,
> + $revdata,
> + $color,
> + $rev,
> + @first);
> + }
> + git_blame_flush_chunk($name,
> + $revdata,
> + $color,
> + $rev,
> + @chunk);
> +}
> +
> sub git_blame2 {
> my $fd;
> my $ftype;
> + my $chunk_cap = 20;
>
> my ($have_blame) = gitweb_check_feature('blame');
> if (!$have_blame) {
> @@ -2475,27 +2530,45 @@ sub git_blame2 {
> <table class="blame">
> <tr><th>Commit</th><th>Line</th><th>Data</th></tr>
> HTML
> + my @chunk = ();
> + my %revdata = ();
> while (<$fd>) {
> /^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
> - my $full_rev = $1;
> - my $rev = substr($full_rev, 0, 8);
> - my $lineno = $2;
> - my $data = $3;
> -
> + my ($full_rev, $author, $date, $lineno, $data) =
> + /^([0-9a-f]{40}).*?\s\((.*?)\s+([-\d]+ [:\d]+ [-+\d]+)\s+(\d+)\)\s(.*)/;
> + if (!exists $revdata{$full_rev}) {
> + $revdata{$full_rev} = "$author, $date";
> + }
> if (!defined $last_rev) {
> $last_rev = $full_rev;
> } elsif ($last_rev ne $full_rev) {
> + git_blame_flush_chunk_1($chunk_cap,
> + $file_name,
> + \%revdata,
> + $rev_color[$current_color],
> + $last_rev, @chunk);
> + @chunk = ();
> $last_rev = $full_rev;
> $current_color = ++$current_color % $num_colors;
> }
> - 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=\"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";
> - print "</tr>\n";
> + elsif ($chunk_cap * 2 < @chunk) {
> + # We have more than N*2 lines from the same
> + # revision. Flush N lines and leave N lines
> + # in @chunk to avoid orphaned lines.
> + my @first = splice(@chunk, 0, $chunk_cap);
> + git_blame_flush_chunk($file_name,
> + \%revdata,
> + $rev_color[$current_color],
> + $last_rev, @first);
> + }
> + push @chunk, [$lineno, $data];
> + }
> + if (@chunk) {
> + git_blame_flush_chunk_1($chunk_cap,
> + $file_name,
> + \%revdata,
> + $rev_color[$current_color],
> + $last_rev, @chunk);
> }
> print "</table>\n";
> print "</div>";
> --
> 1.4.2.3.gbe06
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Luben Tuikov @ 2006-10-03 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsdat4ia.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> > ACK. Please commit.
>
> Won't, at least as its current shape. Somebody privately
> mentioned that the code risks slurping the entire file in the
> @chunk if it is untouched since the initial import, which is not
> what we want.
Indeed that's true.
> The memory consumption worries aside, that would make the
> clickable commit object name to appear only very at the
> beginning of the page and would make it inconvenient to actually
> visit the commit after scrolling down to see later lines.
>
> It might become usable if it is given a cap to limit the number
> of lines to put in a chunk. I dunno.
I cannot imagine this to be a problem, since an initial commit
is "very well known" (hopefully that makes sense to people using
SCMs religously).
I'll give it try.
Luben
^ permalink raw reply
* [PATCH] gitweb: make PATHINFO URL generation conditional on input URL.
From: Martin Waitz @ 2006-10-03 18:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <efu3u4$tc9$1@sea.gmane.org>
Now the feature 'pathinfo' configuration only applies to the project
list. All other URLs are generated in the form the webpage was
called itself.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
gitweb/gitweb.perl | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0ff6f7c..70246de 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -206,6 +206,8 @@ our $git_version = qx($GIT --version) =~
$projects_list ||= $projectroot;
+our $use_pathinfo_url = gitweb_check_feature('pathinfo');
+
# ======================================================================
# input validation and dispatch
our $action = $cgi->param('a');
@@ -226,6 +228,8 @@ if (defined $project) {
undef $project;
die_error(undef, "No such project");
}
+ # we got called without PATH_INFO, let's keep it that way.
+ $use_pathinfo_url = 0;
}
our $file_name = $cgi->param('f');
@@ -308,6 +312,10 @@ sub evaluate_path_info {
undef $project;
return;
}
+
+ # we were called using a PATH_INFO URL, let's keep it that way.
+ $use_pathinfo_url = 1;
+
# do not change any parameters if an action is given using the query string
return if $action;
$path_info =~ s,^$project/*,,;
@@ -402,8 +410,7 @@ sub href(%) {
$params{'project'} = $project unless exists $params{'project'};
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ if ($use_pathinfo_url) {
# use PATH_INFO for project name
$href .= "/$params{'project'}" if defined $params{'project'};
delete $params{'project'};
--
1.4.2.3
--
Martin Waitz
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox