* Re: [PATCH] gitweb: start to generate PATH_INFO URLs
From: Petr Baudis @ 2006-10-06 15:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, git
In-Reply-To: <7v8xk2jofc.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Sep 30, 2006 at 12:30:47AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Martin Waitz <tali@admingilde.org> writes:
>
> > Instead of providing the project as a ?p= parameter it is simply appended
> > to the base URI.
> > All other parameters are appended to that, except for ?a=summary which
> > is the default and can be omitted.
>
> Supporting PATH_INFO in the sense that we do sensible things
> when we get called with one is one thing, but generating such a
> URL that uses PATH_INFO is a different thing. I suspect not
> everybody's webserver is configured to call us with PATH_INFO,
> so this should be conditional.
Hmm, which webservers support CGI but don't pass PATH_INFO?
BTW, couple of notes for people who will want to try it: if gitweb.cgi
serves as your indexfile, this will break; you need to override $my_uri
in gitweb_config. Also, you need to change the default location of CSS,
favicon and logo to an absolute URL.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: prepare for repositories with packed refs.
From: Petr Baudis @ 2006-10-06 15:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsli5pwqf.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Oct 03, 2006 at 11:36:08AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When a repository is initialized long time ago with symbolic
> HEAD, and "git-pack-refs --prune" is run, HEAD will be a
> dangling symlink to refs/heads/ somewhere.
>
> Running -e "$dir/HEAD" to guess if $dir is a git repository does
> not give us the right answer anymore in such a case.
I think this is a wrong answer to this problem - I guess Cogito's going
to be confused by HEAD a dangling symlink as well and I'll bet there's
more places where this will give us trouble. Having HEAD a dangling
symlink is just wrong and git-pack-refs --prune is buggy if it causes
that.
You should fix the problem at that side and make sure it either
changes HEAD to a symref or doesn't pack the ref HEAD points at. Or just
error out and leave the policy decision on the user.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Petr Baudis @ 2006-10-06 15:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Rientjes, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0609270948140.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Wed, Sep 27, 2006 at 09:50:11AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> Git's source code is very clean and readable, even if there are inversions
> you might not be used to.
I think it's a good sign that _this_ is what we argue about. ;-)
--
Petr "Pasky the 10 > x Loather" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* [PATCH] gitweb: Separate (new) and (deleted) in commitdiff by a space
From: Petr Baudis @ 2006-10-06 16:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Currently it's pasted to the sha1 of the blob and looks ugly.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bcb41cc..ea159e9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1987,14 +1987,14 @@ sub git_patchset_body {
print "<div class=\"diff_info\">" . file_type($diffinfo->{'to_mode'}) . ":" .
$cgi->a({-href => href(action=>"blob", hash_base=>$hash,
hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'to_id'}) . "(new)" .
+ $diffinfo->{'to_id'}) . " (new)" .
"</div>\n"; # class="diff_info"
} elsif ($diffinfo->{'status'} eq "D") { # deleted
print "<div class=\"diff_info\">" . file_type($diffinfo->{'from_mode'}) . ":" .
$cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
hash=>$diffinfo->{'from_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'from_id'}) . "(deleted)" .
+ $diffinfo->{'from_id'}) . " (deleted)" .
"</div>\n"; # class="diff_info"
} elsif ($diffinfo->{'status'} eq "R" || # renamed
^ permalink raw reply related
* Re: Unresolved issues #4
From: Jon Loeliger @ 2006-10-06 16:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vfye20xjt.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-10-06 at 01:26, Junio C Hamano wrote:
> From: Franck Bui-Huu <vagabon.xyz@gmail.com>
> Message-ID: <450EABD0.1040102@innova-card.com>
>
> Repeated requests against git-daemon makes it stuck
>
> [jc: does not reproduce easily for me; has anybody seen it?]
I've not seen that behavior either. However, I
suspect that this might be a poorly described
issue with _clients_ that are out of date.
Specifically, if a client is older than 1.4.2.1,
it shows up in the git-daemon log as just a
single "connection from <ipaddr>" line and no
actual transfer then happens, making it perhaps
appear "stuck".
jdl
^ permalink raw reply
* Re: [PATCH] ref-log: allow ref@{count} syntax.
From: Shawn Pearce @ 2006-10-06 16:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsli20y1c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Often I find myself wanting to say 'tip of "next" before I
> merged the last three topics'. Now I can say that with:
>
> git log next@{3}..next
>
> Since small integers alone are invalid input strings to
> approxidate, there is no fear of confusion.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> * The implementation is rather hacky but I think this is
> mildly useful. Likes, dislikes?
Ack'd.
Its a useful feature. Something I've been wanting myself for
some time. I usually just guess with '@{5.minutes.ago}' or some
nonsense until I find the right time. But since I know it was X
operations ago, '@{X}' will be very handy. Thanks!
--
Shawn.
^ permalink raw reply
* Re: Unresolved issues #4
From: Shawn Pearce @ 2006-10-06 16:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eg5co6$g9n$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> > From: Shawn Pearce <spearce@spearce.org>
> > Message-ID: <20060930045037.GB18479@spearce.org>
> >
> > "git ref-log" command to interact with ref-log?
> >
> > [jc: not much interest from users?]
>
> I thing it can increase number of reflog users.
Agreed and I'd really like to see that command but I have not had the
time to do code it myself. What time I am able to make available
for Git in the near future needs to be for the window mmap rewrite
ontop of Nico's delta offset changes that are currently in next.
If nobody gets around to it I'll likely try to pick it up and do it,
but that probably won't be for at least a month, maybe two.
--
Shawn.
^ permalink raw reply
* Re: Unresolved issues #4
From: Shawn Pearce @ 2006-10-06 16:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfye20xjt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> From: Shawn Pearce <spearce@spearce.org>
> Message-ID: <20060926215745.GC8177@spearce.org>
>
> git-mirror (reverse of git-push --all).
>
> [jc: any progress?]
No. Back burner. Waaaaaaay back. I have your comments and I'd
like to incorporate them and resubmit but I've had other things
demanding my time.
--
Shawn.
^ permalink raw reply
* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Petr Baudis @ 2006-10-06 16:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Luben Tuikov, Jakub Narebski, Ryan Anderson,
Johannes Schindelin, Martin Langhoff, Martyn Smith,
Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <7vu02jfaec.fsf_-_@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Oct 05, 2006 at 10:13:15AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> It's been a while since we lost git_blame from %actions list. I
> am wondering maybe it's time to remove it, after 1.4.3 happens.
I will not mourn git-annotate disappearance (perhaps it could stay an
alias to git-blame -c; I don't like this UI-wise but we already do this
kind of thing with git-log / git-whatchanged). I still like gitweb blame
better than blame2 but I'll just patch blame to look like blame2 (or
better) and be happy with that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Remove bashism from t3210-pack-refs.sh
From: Linus Torvalds @ 2006-10-06 16:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eg5r9k$58c$1@sea.gmane.org>
On Fri, 6 Oct 2006, Jakub Narebski wrote:
> Alex Riesen wrote:
>
> > On 10/6/06, Dennis Stosberg <dennis@stosberg.net> wrote:
> >> - SHA1=$(< .git/refs/heads/a) &&
> >> + SHA1=`cat .git/refs/heads/a` &&
> >
> > Only "<" (the redirection part) is bashism. The "$()" is POSIX.
>
> BTW. it is not packed-refs safe.
Well, since that seems to be a test-case for the packed-refs thing, that's
probably not a problem ;)
In a real-life git script you should do something like
SHA1=$(git-rev-parse --verify "refs/heads/$head^0") && ...
to get the SHA1 and verify that it's all good, but since that script is
all about checking that packing does the right thing, I think it's fine to
do it by hand there..
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view
From: Petr Baudis @ 2006-10-06 16:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eg51fi$7rs$2@sea.gmane.org>
Dear diary, on Fri, Oct 06, 2006 at 09:44:29AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Gaah, the whole cae1862a3b55b487731e9857f2213ac59d5646d commit
> "gitweb: More per-view navigation bar links" is somewhat broken.
> Up to this point we used top navigation bar for commit (hash base)
> or whole project related links, while bottom part of navigation
> bar for "formats" i.e. links related to current view (passing hash)
> or for pagination.
Umm, and how did that commit break that? Except the issue this patch
fixes - sorry about that, I have no idea wth was I thinking.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: git-send-email w/ headers
From: David Woodhouse @ 2006-10-06 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Len Brown, git
In-Reply-To: <7viriy9w1q.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-10-05 at 16:34 -0700, Junio C Hamano wrote:
> Len Brown <len.brown@intel.com> writes:
>
> > git-send-email seems to strip out my custom headers.
>
> It seems to not care about anything but a selected few.
>
> Could you give this a try, please?
It also needs to preserve (and indeed to provide by default)
Content-Type headers to specify the character set.
--
dwmw2
^ permalink raw reply
* Re: Unresolved issues #4
From: A Large Angry SCM @ 2006-10-06 16:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vfye20xjt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Recent issues I am aware of but haven't kept track of closely
> enough and as a result do not have a clue about X-<.
>
> From: A Large Angry SCM <gitzilla@gmail.com>
> Subject: Notes on Using Git with Subprojects
> Message-ID: <45196628.9010107@gmail.com>
>
> [jc: a very nice write-up of a subprojects workflow. I do not
> remember if it produced any actionable items, though]
>
No actionable items that I'm aware of.
^ permalink raw reply
* [PATCH] gitweb: Handle commits with empty commit messages more reasonably
From: Petr Baudis @ 2006-10-06 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20061006135508.GO20017@pasky.or.cz>
Currently those look very weird, you can't get easily at the commit view
etc. This patch makes their title '(no commit message)'.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ea159e9..56e5231 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1115,6 +1115,9 @@ sub parse_commit {
last;
}
}
+ if ($co{'title'} eq "") {
+ $co{'title'} = $co{'title_short'} = '(no commit message)';
+ }
# remove added spaces
foreach my $line (@commit_lines) {
$line =~ s/^ //;
^ permalink raw reply related
* [PATCH] gitweb: [commit view] Do not suppress commitdiff link in root commit
From: Petr Baudis @ 2006-10-06 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There's no reason for that, the commitdiff view is meaningful for the
root commit as well and we link to it everywhere else.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 56e5231..3a10124 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3034,7 +3034,7 @@ sub git_commit {
$cgi->a({-href => href(action=>"log", hash=>$hash)}, "log");
}
git_header_html(undef, $expires);
- git_print_page_nav('commit', defined $co{'parent'} ? '' : 'commitdiff',
+ git_print_page_nav('commit', '',
$hash, $co{'tree'}, $hash,
join (' | ', @views_nav));
^ permalink raw reply related
* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Luben Tuikov @ 2006-10-06 17:52 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano
Cc: git, Luben Tuikov, Petr Baudis, Jakub Narebski, Ryan Anderson,
Martin Langhoff, Martyn Smith, Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0610061505360.14200@wbgn013.biozentrum.uni-wuerzburg.de>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 5 Oct 2006, Junio C Hamano wrote:
>
> > Do people have reason to favor annotate over blame? To keep
> > existing people's scripts working I think we should add a small
> > amount of code to blame.c to default to compatibility mode when
> > the command is called as git-annotate at least for a while, but
> > other than that I do not see much issue against scheduling for
> > annotate's removal.
>
> +1. Although I would leave git-annotate in git, if only to meet
> expectations of new git users.
I agree with Junio's assessment of the situation.
Luben
^ permalink raw reply
* git show and gitweb gives different result for kernel
From: Aneesh Kumar K.V @ 2006-10-06 17:56 UTC (permalink / raw)
To: git
Hi All,
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=363e065c02b1273364d5356711a83e7f548fc0c8
git show 363e065c02b1273364d5356711a83e7f548fc0c8
git show gives the correct values.
-aneesh
^ permalink raw reply
* Commit to more than one branch at once?
From: Stefan Richter @ 2006-10-06 18:18 UTC (permalink / raw)
To: git
Hi all,
if I git-cherry-pick a commit from branch A into branch B, this is shown
as a difference in "git-log B..A".
Is it possible to commit a change to two or more branches but preserve
the identity of the change? IOW, is there an alternative to
git-cherry-pick that does not have above mentioned side effect?
--
Stefan Richter
-=====-=-==- =-=- --==-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: gitweb: using quotemeta
From: Luben Tuikov @ 2006-10-06 18:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20061006135019.GN20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Mon, Oct 02, 2006 at 10:12:56PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > Escaping for the purposes of HTML _view_ and URL generation is ok,
> > but it is not ok when _saving_ the file with a file name.
> >
> > A file name is just a string of chars, and I want to _save_ the file
> > name as its name is. No changes or interpretations please. I don't
> > care what the string is, what chars it is made of, etc.
> >
> > Please don't interpret file names and their characters when the files
> > are _saved_ by the user's browser.
> >
> > The file name in my filesystem should be the exact same file name
> > as it appears on any other filesystem hosting the same git repo.
> >
> > I don't want this translation:
> > Server FS: linux-2.6.git-5c2d97cb31fb77981797fec46230ca005b865799.tar.gz
> > Quotemeta: linux\-2\.6\.git\-5c2d97cb31fb77981797fec46230ca005b865799\.tar\.gz
> > User FS: linux\-2\.6\.git\-5c2d97cb31fb77981797fec46230ca005b865799\.tar\.gz
>
> Then the user agent is buggy - which browser exhibits this behaviour?
Latest greatest Firefox for Linux. And no, I don't think that
the browser is broken.
> According to RFC2183, the filename is a value. According to RFC2045, a
> value is either a token (uninteresting) or a quoted-string. According to
> RFC822:
>
> quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
> ; quoted chars.
>
> qtext = <any CHAR excepting <">, ; => may be folded
> "\" & CR, and including
> linear-white-space>
>
> quoted-pair = "\" CHAR ; may quote any char
>
> So what we emit is completely correct.
(Your quotations do not seem correct according to
ftp://ftp.rfc-editor.org/in-notes/rfc2045.txt !)
Petr, I agree with your that what we emit is "completely correct".
But is is _mangled_. I.e. why mangle the filename from "a.b" to
"a\.b" ? Indeed the latter _is_ qtext but it is not the original name
given to the file.
What actually happened is that _gitweb_ itself mangles the name.
> Of course I have nothing against escaping just ", \ and CR. I don't mind
> just substituting CR with some other string, but please just quote " and
> \ correctly.
Indeed, these three are the only chars NOT ALLOWED in qtext.
Will quote those. Thanks for pointing this out.
> As of now, gitweb will not handle any filenames containing those three
> characters properly because of now.
Will fix.
Thanks,
Luben
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>
^ permalink raw reply
* Re: gitweb: using quotemeta
From: Luben Tuikov @ 2006-10-06 18:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
--- Luben Tuikov <ltuikov@yahoo.com> wrote:
> --- Petr Baudis <pasky@suse.cz> wrote:
> > Dear diary, on Mon, Oct 02, 2006 at 10:12:56PM CEST, I got a letter
> > where Luben Tuikov <ltuikov@yahoo.com> said that...
> > > Escaping for the purposes of HTML _view_ and URL generation is ok,
> > > but it is not ok when _saving_ the file with a file name.
> > >
> > > A file name is just a string of chars, and I want to _save_ the file
> > > name as its name is. No changes or interpretations please. I don't
> > > care what the string is, what chars it is made of, etc.
> > >
> > > Please don't interpret file names and their characters when the files
> > > are _saved_ by the user's browser.
> > >
> > > The file name in my filesystem should be the exact same file name
> > > as it appears on any other filesystem hosting the same git repo.
> > >
> > > I don't want this translation:
> > > Server FS: linux-2.6.git-5c2d97cb31fb77981797fec46230ca005b865799.tar.gz
> > > Quotemeta: linux\-2\.6\.git\-5c2d97cb31fb77981797fec46230ca005b865799\.tar\.gz
> > > User FS: linux\-2\.6\.git\-5c2d97cb31fb77981797fec46230ca005b865799\.tar\.gz
> >
> > Then the user agent is buggy - which browser exhibits this behaviour?
>
> Latest greatest Firefox for Linux. And no, I don't think that
> the browser is broken.
>
> > According to RFC2183, the filename is a value. According to RFC2045, a
> > value is either a token (uninteresting) or a quoted-string. According to
> > RFC822:
> >
> > quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
> > ; quoted chars.
> >
> > qtext = <any CHAR excepting <">, ; => may be folded
> > "\" & CR, and including
> > linear-white-space>
> >
> > quoted-pair = "\" CHAR ; may quote any char
> >
> > So what we emit is completely correct.
>
> (Your quotations do not seem correct according to
> ftp://ftp.rfc-editor.org/in-notes/rfc2045.txt !)
>
> Petr, I agree with your that what we emit is "completely correct".
>
> But is is _mangled_. I.e. why mangle the filename from "a.b" to
> "a\.b" ? Indeed the latter _is_ qtext but it is not the original name
> given to the file.
Sorry, I ment to say that the latter doesn't appear to be qtext.
Bottomline is that quotemeta does not convert into qtext, and as thus
should never have been used.
Will fix as per your suggestions.
Luben
>
> What actually happened is that _gitweb_ itself mangles the name.
>
> > Of course I have nothing against escaping just ", \ and CR. I don't mind
> > just substituting CR with some other string, but please just quote " and
> > \ correctly.
>
> Indeed, these three are the only chars NOT ALLOWED in qtext.
> Will quote those. Thanks for pointing this out.
>
> > As of now, gitweb will not handle any filenames containing those three
> > characters properly because of now.
>
> Will fix.
>
> Thanks,
> Luben
>
>
>
> >
> > --
> > Petr "Pasky" Baudis
> > Stuff: http://pasky.or.cz/
> > #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> > $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> > lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> >
>
>
^ permalink raw reply
* Re: [PATCH] gitweb: Remove redundant "commit" link from shortlog
From: Luben Tuikov @ 2006-10-06 18:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061006135508.GO20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Sep 29, 2006 at 01:48:40AM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > Remove the redundant "commit" link from shortlog.
> > It can be had by simply clicking on the entry title
> > of the row.
> >
> > Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
>
> And what if the commit message is empty?
>
> Witness at http://repo.or.cz/?p=test;a=summary
Clearly a pathological case. Who or why would anyone do this?
I don't think we should worry about such pathological cases.
Commits without commit messages do not question GIT. They
question the committer... (that's the morning chuckle)
Luben
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> -
> 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
* [PATCH] gitweb: Support hiding of chosen repositories from project list
From: Petr Baudis @ 2006-10-06 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This makes it possible to hide certain repository from project list
(while still keeping it accessible, so it's not just an inverse of
export-ok). By default the file that needs to be created in the
repository is '.hide'.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Makefile | 2 ++
gitweb/gitweb.perl | 11 +++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index a151029..afb29e9 100644
--- a/Makefile
+++ b/Makefile
@@ -125,6 +125,7 @@ GITWEB_HOME_LINK_STR = projects
GITWEB_SITENAME =
GITWEB_PROJECTROOT = /srv/git
GITWEB_EXPORT_OK =
+GITWEB_HIDE_REPO = .hide
GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
GITWEB_LIST =
@@ -673,6 +674,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
-e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
-e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
+ -e 's|++GITWEB_HIDE_REPO++|$(GITWEB_HIDE_REPO)|g' \
-e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
-e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
-e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3a10124..b06e96a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -66,6 +66,11 @@ # show repository only if this file exis
# (only effective if this variable evaluates to true)
our $export_ok = "++GITWEB_EXPORT_OK++";
+# hide repository from the list if this file exists
+# (the repository is still accessible, just not shown in the project list)
+# (only effective if this variable evaulates to true)
+our $hide_repo = "++GITWEB_HIDE_REPO++";
+
# only allow viewing of repositories also shown on the overview page
our $strict_export = "++GITWEB_STRICT_EXPORT++";
@@ -864,7 +869,8 @@ sub git_get_projects_list {
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
- if (check_export_ok("$projectroot/$subdir")) {
+ if ((!$hide_repo or ! -e "$projectroot/$subdir/$hide_repo")
+ and check_export_ok("$projectroot/$subdir")) {
push @list, { path => $subdir };
$File::Find::prune = 1;
}
@@ -885,7 +891,8 @@ sub git_get_projects_list {
if (!defined $path) {
next;
}
- if (check_export_ok("$projectroot/$path")) {
+ if ((!$hide_repo or ! -e "$projectroot/$path/$hide_repo")
+ and check_export_ok("$projectroot/$path")) {
my $pr = {
path => $path,
owner => decode("utf8", $owner, Encode::FB_DEFAULT),
^ permalink raw reply related
* Re: git show and gitweb gives different result for kernel
From: Martin Waitz @ 2006-10-06 18:30 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <eg65cl$cvs$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
hoi :)
On Fri, Oct 06, 2006 at 11:26:35PM +0530, Aneesh Kumar K.V wrote:
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=363e065c02b1273364d5356711a83e7f548fc0c8
>
> git show 363e065c02b1273364d5356711a83e7f548fc0c8
what do you mean? the diff?
git show uses diff --cc so that only changes which are not in
the parent trees are shown.
gitweb just diffs against the first parent, and this diff is
large in your example because a new upstream Linux kernel
got merged into a topic branch. But it should still be correct.
But perhaps gitweb should use --cc, too.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Commit to more than one branch at once?
From: Linus Torvalds @ 2006-10-06 18:37 UTC (permalink / raw)
To: Stefan Richter; +Cc: git
In-Reply-To: <45269E02.50407@s5r6.in-berlin.de>
On Fri, 6 Oct 2006, Stefan Richter wrote:
>
> if I git-cherry-pick a commit from branch A into branch B, this is shown
> as a difference in "git-log B..A".
>
> Is it possible to commit a change to two or more branches but preserve
> the identity of the change? IOW, is there an alternative to
> git-cherry-pick that does not have above mentioned side effect?
If you _merge_ the change into both branches, it will be the identical
commit in both.
So for example, one thing people can do is to have a separate "fixes"
branch that is used for generic bugfixes and, which is merged into all
other relevant branches.
Linus
^ permalink raw reply
* Re: Commit to more than one branch at once?
From: Sean @ 2006-10-06 18:38 UTC (permalink / raw)
To: Stefan Richter; +Cc: git
In-Reply-To: <45269E02.50407@s5r6.in-berlin.de>
On Fri, 06 Oct 2006 20:18:42 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> if I git-cherry-pick a commit from branch A into branch B, this is shown
> as a difference in "git-log B..A".
>
> Is it possible to commit a change to two or more branches but preserve
> the identity of the change? IOW, is there an alternative to
> git-cherry-pick that does not have above mentioned side effect?
Short answer:
No.
Slightly longer answer:
Only merging the branches will make the commit show up in branch B with
the same SHA1 number (or identity) that it had in branch A. This is a
fundamental part of Git. The sha1 of each commit is based in part on
the sha1 of its parent. Thus it's impossible[1] to copy a commit to
another branch (ie. reparent it) without changing its identity.
Sean
[1] Okay, more or less impossible.. don't ask me do the math.
^ 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