* Re: git and time
From: Jakub Narebski @ 2006-10-02 23:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vd59d7y8v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Sat, 30 Sep 2006, Junio C Hamano wrote:
>>
>>> Shawn Pearce <spearce@spearce.org> writes:
>>>
>>> > Agreed. I've been missing such a command and have wanted to add
>>> > one but it wasn't important enough to me to actually code it. :)
>>>
>>> Everything you said in your message sounds sane and makes sense
>>> to me. Now we have to find a sucker^Wvolunteer to implement it
>>> ;-).
>>
>> Ehh. As far as I can see it's
>> - a damn hard thing to do efficiently
>> - essentially exactly the same problem you already solved with "git
>> describe"
>>
>> In other words, I think you could make git describe do it, by simply
>> making it parse not just all tags, but also walking the branch log.
>
> As a user interface, I think it makes a lot of sense to have
> "git describe" do it without introducing a new command.
>
> However, I think the traditional "find the closest ancestor"
> behaviour and ref-log behaviour are mutually incompatible, while
> they both return information to help address similar issues to
> the end user when viewed at a very high level.
>
> Especially, "find the closest ancestor" behaviour means when you
> get "tag-gXXXX" as an answer, the tag proper does _not_ contain
> the given commit (e.g. commit v1.4.2-g4839bd8 is not part of
> v1.4.2). To answer "when did the fix deadbeef go into master
> branch", reporting "master@{yesterday}-gdeadbeef" with the same
> logic and format is misleading; "master@{yesterday}" may be the
> closest ancestor of commit deadbeef, but that means it does
> _not_ contain the fix. When walking ref-log, we want it the
> other way around: "find the earliest descendant among the
> entries in ref-log for a particular branch".
>
> The internal logic for doing that may be somewhat different and
> I suspect you may not be able to share much code with the
> existing logic..
Isn't git-name-rev doing kind of earliest descendant among refs?
Well, I'm not sure if name-rev does not use shortest description
instead of earliest (closest) descendant... but we could extend it.
I'd like also to limit refs used to given pattern, and perhaps
also to only tag objects.
This is command to extend it using it together with ref-log to know
when given fix appeared in repository.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git and time
From: Jakub Narebski @ 2006-10-03 0:01 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609261849430.3952@g5.osdl.org>
Linus Torvalds wrote:
> Now, in some sense, you can ignore the difference between the two models,
> since you'd think that they are totally equivalent: from the git model,
> you can always get the "changeset" by just diffing the current state with
> the previous state, and conversely from the "changeset" model you can
> always get the "current state" by just applying the changeset to the
> previous state.
And if I understand correctly, that is how StGit and pg (Patchy Git), which
are patch management applications similar in the purpose to the Quilt, and
are based on Git, works.
http://wiki.procode.org/cgi-bin/wiki.cgi/StGITtheory
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Error in test description of t1200-tutorial
From: Robin Rosenberg @ 2006-10-03 0:02 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
t/t1200-tutorial.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index c7db20e..0272dd4 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -3,7 +3,7 @@ #
# Copyright (c) 2005 Johannes Schindelin
#
-test_description='Test git-rev-parse with different parent options'
+test_description='A simple turial in the form of a test case'
. ./test-lib.sh
^ permalink raw reply related
* Re: Multiple checkouts of the same repository
From: Daniel Barkalow @ 2006-10-03 2:52 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Johannes Schindelin, git
In-Reply-To: <3bbc18d20610011404x52d8ba15ib51ac2a7060bd25e@mail.gmail.com>
On Sun, 1 Oct 2006, Matt McCutchen wrote:
> On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > The fact is, your setup is fragile, and I think that is hard to fix if you
> > do not make A and B git repositories in their own right.
>
> I think my setup is much simpler than having two separate repositories
> that update each other using hooks. What can go wrong, besides the
> scenario I mentioned where one working tree doesn't get updated when I
> commit through the other one?
It works fine, so long as you never modify in A the head that's checked
out in B; if you do this, git will be very confused, because it doesn't
record in the index what commit the index comes from. I did this for a
while, but eventually switched to just having a single branch checked out
at a time. (The other thing is that you probably want to have the
non-symlinked repository be bare, i.e., not checked out, and have multiple
sets of symlinks to its parts, so if you decide to discard a working
directory, you don't accidentally delete the one with the repository
actually in it.)
At one point, I was arguing for storing the information of what commits
were the starting point of the current index in the index itself, instead
of relying on external files and external links to refs, but I wasn't
really working on git enough to argue for it effectively. Among other
things, it would allow git to know what's going on if the head changes
without the index getting updated. (Of course, all of the cases it
supports are really ones where git should just tell you that you've done
something wrong, because you can't really do non-linear work in a single
head sensibly, because there's only one ref for the head, which can't jump
sideways from the commit that's been pulled or generated elsewhere to the
commit that's being generated from the index; if the head doesn't match
the commit the index is from, there is no alternative to a
merge-before-commit, which is frowned upon in the git world as a way of
losing your recent work. This is why I couldn't convince people very
well.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Junio C Hamano @ 2006-10-03 4:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610022203.44733.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Luben Tuikov wrote:
>> --- Jakub Narebski <jnareb@gmail.com> wrote:
>>> I think that redundancy in a visual interface (and not only visual, as
>>> seen in the example of Perl programming language) is a good idea,
>>> contrary to the redundancy in code or data (database).
>>
>> Jakub,
>>
>> Your opinion here is highly subjective.
>
> Yours too.
>
>> Years of experience make certain things "make sense" and other
>> "make less sense". Note that that is in itself subjective.
>>
>> Give it 10 years, your opinion will change.
>
> Perhaps. Perhaps not.
>
> I guess we have to agree to disagree. It's Junio opinion that
> matters (which patches would get accepted).
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.
I personally feel that in a list that is one line per item, like
the shortlog, we do not necessarily have to underline the log
message even though they are clickable. The purpose of the list
is to show things so people can read them. Readability matters.
At the same time we would want to give access to object details;
I think it is Ok not to give underline to them, as long as
people can easily pick up the convention that each of these
listed items is clickable to obtain details about it. We should
probably make other clickable links at the right, such as "tree"
and "snapshot", visually stand out, by giving underline as we
already do. They are not really "text", but clickable icons
that happen to be done with text (as opposed to being done with
img).
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.
By the way, you are right in saying if we were to do icons they
should be out-of-line img with help for text browsers. That
patch was done as illustration not as a serious patch (I am not
a serious gitweb hacker, so anything I do with gitweb, unless it
is an obvious and trivial bugfix, is not meant for direct
inclusion).
^ permalink raw reply
* Re: [PATCH] lock_ref_sha1_basic does not remove empty directories on BSD
From: Junio C Hamano @ 2006-10-03 4:14 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20061002172353.G44b12bbc@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> lock_ref_sha1_basic relies on errno beeing set to EISDIR by the
> call to read() in resolve_ref() to detect directories. But calling
> read() on a directory under NetBSD returns EPERM, and even succeeds
> for local filesystems on FreeBSD.
>
> Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Thanks.
I've always wondered about the code that follows where you
patched. It relies on either open() on a directory to fail, or
read() from a file descriptor to return something other than
what starts with 40-byte hexadecimal (or "ref: blah") to skip
directories.
You might probably meant the patch primarily to fix the leftover
empty directories issue in "next", but it is also the right
thing to do for "master" (and even for "maint"), I think.
I'll apply it to "master" and then merge it into "next".
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Junio C Hamano @ 2006-10-03 4:19 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061002192930.86293.qmail@web31803.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>
>> 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>
>> ---
>
> 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.
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.
^ permalink raw reply
* Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt
From: Junio C Hamano @ 2006-10-03 5:52 UTC (permalink / raw)
To: Stefan Richter; +Cc: git
In-Reply-To: <tkrat.4532d38d43e16a62@s5r6.in-berlin.de>
Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
> fixes a failure to build the git-rev-parse manpage,
> seen with asciidoc 8.0.0
>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index b761b4b..671b4e3 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -138,7 +138,7 @@ syntax.
> 'rev{caret}0' means the commit itself and is used when 'rev' is the
> object name of a tag object that refers to a commit object.
>
> -* A suffix '~<n>' to a revision parameter means the commit
> +* 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
> equivalent to rev{caret}{caret}{caret} which is equivalent to\
But this makes it asciidoc 7.1 barf, so we need an alternative
compatible to both.
This works for me on 7.1; is your 8.0 happy with it?
-- >8 --
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 8196d78..44b1ce4 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -11,6 +11,7 @@ # the command.
caret=^
startsb=[
endsb=]
+tilde=~
ifdef::backend-docbook[]
[gitlink-inlinemacro]
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index b761b4b..2f1306c 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -138,7 +138,7 @@ syntax.
'rev{caret}0' means the commit itself and is used when 'rev' is the
object name of a tag object that refers to a commit object.
-* A suffix '~<n>' to a revision parameter means the commit
+* A suffix '{tilde}<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
equivalent to rev{caret}{caret}{caret} which is equivalent to\
^ permalink raw reply related
* Re: gitweb: using quotemeta
From: Junio C Hamano @ 2006-10-03 6:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610022250.32029.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> But you forget that in HTTP headers, to be more exact in
> Content-Disposition: inline; filename="<filename>"
> header, the quote '"' and end-of-line '\n' characters in <filename>
> are treated specially. So you need to quote somehow at least those
> two characters.
True, but untrue. This is just a suggestion so we do not _have_
to quote. We only need to avoid spitting out dq and lf
literally. We could even just do something like the attached if
we wanted to:
s/[^ -~]+/?/g ;# replace each sequence of bytes outside
# ' ' to '~' range to a '?'
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 44991b1..e7202ee 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2651,7 +2651,7 @@ sub git_blob_plain {
# save as filename, even when no $file_name is given
my $save_as = "$hash";
if (defined $file_name) {
- $save_as = $file_name;
+ ($save_as = $file_name) =~ s/[^ -~]+/?/g;
} elsif ($type =~ m/^text\//) {
$save_as .= '.txt';
}
@@ -2830,6 +2830,7 @@ sub git_snapshot {
}
my $filename = basename($project) . "-$hash.tar.$suffix";
+ $filename =~ s/[^ -~]+/?/g;
print $cgi->header(
-type => 'application/x-tar',
@@ -3139,6 +3140,7 @@ sub git_blobdiff {
}
} elsif ($format eq 'plain') {
+ $file_name =~ s/[^ -~]+/?/g;
print $cgi->header(
-type => 'text/plain',
-charset => 'utf-8',
@@ -3241,6 +3243,7 @@ sub git_commitdiff {
my $refs = git_get_references("tags");
my $tagname = git_get_rev_name_tags($hash);
my $filename = basename($project) . "-$hash.patch";
+ $filename =~ s/[^ -~]+/?/g;
print $cgi->header(
-type => 'text/plain',
^ permalink raw reply related
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Junio C Hamano @ 2006-10-03 7:25 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <7vpsdat4ia.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>> --- Junio C Hamano <junkio@cox.net> wrote:
>>
>>> 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.
>>...
>> 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.
>
> 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.
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.
-- >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
^ permalink raw reply related
* Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt
From: Stefan Richter @ 2006-10-03 7:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcymt07a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
...
> This works for me on 7.1; is your 8.0 happy with it?
...
> +tilde=~
...
> -* A suffix '~<n>' to a revision parameter means the commit
> +* A suffix '{tilde}<n>' to a revision parameter means the commit
...
Yes, this works as intended. Thanks,
--
Stefan Richter
-=====-=-==- =-=- ---==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Multiple checkouts of the same repository
From: Junio C Hamano @ 2006-10-03 7:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, git, Matt McCutchen
In-Reply-To: <Pine.LNX.4.64.0610022234330.9789@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> At one point, I was arguing for storing the information of what commits
> were the starting point of the current index in the index itself, instead
> of relying on external files and external links to refs, but I wasn't
> really working on git enough to argue for it effectively. Among other
> things, it would allow git to know what's going on if the head changes
> without the index getting updated. (Of course, all of the cases it
> supports are really ones where git should just tell you that you've done
> something wrong,...
I think if you really wanted to, you could put it in the index
extension section along with the cache-tree data. We would need
to implement a way to query and manipulate data in the index
extension and update git-commit (it should check HEAD matches
the commit you placed in the extension earlier, and after making
a commit and updating HEAD, you should update the index with the
new commit as well), git-checkout (after switching branches you
should update the index with the branch head you switched to; I
think you should sanity check before switching to see if the
current index and HEAD are reasonable as well but I am not
sure), git-reset --hard (set to the resetted HEAD), git-am,
git-applymbox, and git-merge (check before and set after when
successful).
^ permalink raw reply
* Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt
From: Junio C Hamano @ 2006-10-03 8:00 UTC (permalink / raw)
To: Stefan Richter; +Cc: git
In-Reply-To: <452211C2.8020402@s5r6.in-berlin.de>
Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
> Junio C Hamano wrote:
> ...
>> This works for me on 7.1; is your 8.0 happy with it?
> ...
>> +tilde=~
> ...
>> -* A suffix '~<n>' to a revision parameter means the commit
>> +* A suffix '{tilde}<n>' to a revision parameter means the commit
> ...
>
> Yes, this works as intended. Thanks,
Thanks. It's a bit sad that asciidoc's nicer quoting features
are not backward compatible.
^ permalink raw reply
* [PATCH] gitweb: document webserver configuration for common gitweb/repo URLs.
From: Martin Waitz @ 2006-10-03 8:03 UTC (permalink / raw)
To: git
Add a small apache configuration which shows how to use apache
to put gitweb and GIT repositories at the same URL.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
I've been running such a configuration on git.admingilde.org for quite
some time now, it's time to document it:
gitweb/README | 26 +++++++++++++++++++++++++-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 27c6dac..61c7ab5 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -1,4 +1,5 @@
GIT web Interface
+=================
The one working on:
http://www.kernel.org/git/
@@ -6,7 +7,8 @@ The one working on:
From the git version 1.4.0 gitweb is bundled with git.
-How to configure gitweb for your local system:
+How to configure gitweb for your local system
+---------------------------------------------
You can specify the following configuration variables when building GIT:
* GITWEB_SITENAME
@@ -29,6 +31,28 @@ You can specify the following configurat
environment variable will be loaded instead of the file
specified when gitweb.cgi was created.
+
+Webserver configuration
+-----------------------
+
+If you want to have one URL for both gitweb and your http://
+repositories, you can configure apache like this:
+
+<VirtualHost www:80>
+ ServerName git.domain.org
+ DocumentRoot /pub/git
+ RewriteEngine on
+ RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
+</VirtualHost>
+
+The above configuration expects your public repositories to live under
+/pub/git and will serve them as http://git.domain.org/dir-under-pub-git,
+both as cloneable GIT URL and as browseable gitweb interface.
+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.
+
+
+
Originally written by:
Kay Sievers <kay.sievers@vrfy.org>
--
1.4.2.gb8b6b
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-10-03 8:18 UTC (permalink / raw)
To: Junio C Hamano, Luben Tuikov; +Cc: git
In-Reply-To: <7v1wpqujck.fsf@assigned-by-dhcp.cox.net>
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... ;-)
> I personally feel that in a list that is one line per item, like
> the shortlog, we do not necessarily have to underline the log
> message even though they are clickable. The purpose of the list
> is to show things so people can read them. Readability matters.
> At the same time we would want to give access to object details;
> I think it is Ok not to give underline to them, as long as
> people can easily pick up the convention that each of these
> listed items is clickable to obtain details about it.
And the current convention of underlining "hidden links", like
the subject line in shortlog/log/heads/history view, is a good
hint of the convention.
> We should
> probably make other clickable links at the right, such as "tree"
> and "snapshot", visually stand out, by giving underline as we
> already do. They are not really "text", but clickable icons
> that happen to be done with text (as opposed to being done with
> img).
Additionally we use slightly smaller font for those links
(in addition to using default style for links).
> 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 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.
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.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: gitweb commitdiff output error
From: Jakub Narebski @ 2006-10-03 9:01 UTC (permalink / raw)
To: git
In-Reply-To: <4b3406f0609280020m43695511qb5da5a3394ad6417@mail.gmail.com>
Dongsheng Song wrote:
> When the file enconding is not utf8, the gitweb commitdiff output
> error for non-ascii characters.
>
> Can I do iconv for commitdiff ?
You can, most probably, but perhaps not as something that is universal.
In git you can set commit message encoding, but git does not remember
(and has no set place where to save it) information about file encoding.
You would have either use default UTF-8 encoding of gitweb page, and do
iconv equivalent, by using "encoding" module and/or "Encode" module,
and by opening diff with "-|:encoding(utf16)" (where of course you have
to put correct encoding). And you would have to set default file encoding
(and perhaps filename encoding) somewhere.
Still, it wouldn't help for example diff of encoding _change_...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Jakub Narebski @ 2006-10-03 9:02 UTC (permalink / raw)
To: git
In-Reply-To: <4b3406f0609280032y77cb5961i220b3cfd741ebfd4@mail.gmail.com>
Dongsheng Song wrote:
> My git repository import from subversion, and the latest files has
> correct mime-type property, but gitweb commitdiff NO diff output !
>
> file:82dc767b3f1425435fa6d8fa7511718d3f614172 ->
> file:4c7269ed65bf8691c46541497fbecc706f7d012f
>
> file:6817671d9af75b9adcc439d62f9047c7b2a9adb2 ->
> file:575d40108f550ac5965bb6ea8b6792fa9cc10536
Not enough information.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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 9:09 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20061001223304.d37df36f.chriscool@tuxfamily.org>
Thanks. We also need this to avoid refetching already packed
tags.
-- >8 --
[PATCH] git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-fetch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index f1522bd..e8a7668 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -417,7 +417,7 @@ case "$no_tags$tags" in
sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
while read sha1 name
do
- test -f "$GIT_DIR/$name" && continue
+ git-show-ref --verify --quiet -- $name && continue
git-check-ref-format "$name" || {
echo >&2 "warning: tag ${name} ignored"
continue
--
1.4.2.3.gd1e9e
^ permalink raw reply related
* Re: [PATCH] gitweb: Add snapshot to shortlog
From: Jakub Narebski @ 2006-10-03 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <20060928235009.92537.qmail@web31811.mail.mud.yahoo.com>
Luben Tuikov wrote:
> Add snapshot to each commit-row of shortlog.
You should add it conditionally, checking for gitweb_have_snapshot.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Add snapshot to log; remove redundant commit from log
From: Jakub Narebski @ 2006-10-03 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <20060928235050.63085.qmail@web31808.mail.mud.yahoo.com>
Luben Tuikov wrote:
> This removes redundant "commit" from log in favor of adding
> "snapshot".
"Snapshot" link should be added gitweb_have_snapshot conditionally.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] pack-refs: use lockfile as everybody else does.
From: Junio C Hamano @ 2006-10-03 9:19 UTC (permalink / raw)
To: torvalds; +Cc: git
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
I failed to spot a difference from the result/lock-path thing in
builtin-pack-ref and what lockfile interface does for refs and
index file. They seem to do the essentially same thing. Did I
miss something?
Also I am not sure about the "fsync(fd); fclose(refs_file)"
sequence I did not touch with this patch. Doesn't stdio still
have stuff buffered when you run fsync()? Would adding fflush()
in between help?
builtin-pack-refs.c | 21 ++++-----------------
1 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c
index 4093973..ede4743 100644
--- a/builtin-pack-refs.c
+++ b/builtin-pack-refs.c
@@ -1,7 +1,6 @@
#include "cache.h"
#include "refs.h"
-static const char *result_path, *lock_path;
static const char builtin_pack_refs_usage[] =
"git-pack-refs [--prune]";
@@ -17,12 +16,6 @@ struct pack_refs_cb_data {
FILE *refs_file;
};
-static void remove_lock_file(void)
-{
- if (lock_path)
- unlink(lock_path);
-}
-
static int do_not_prune(int flags)
{
/* If it is already packed or if it is a symref,
@@ -69,6 +62,8 @@ static void prune_refs(struct ref_to_pru
}
}
+static struct lock_file packed;
+
int cmd_pack_refs(int argc, const char **argv, const char *prefix)
{
int fd, i;
@@ -88,14 +83,7 @@ int cmd_pack_refs(int argc, const char *
if (i != argc)
usage(builtin_pack_refs_usage);
- result_path = xstrdup(git_path("packed-refs"));
- lock_path = xstrdup(mkpath("%s.lock", result_path));
-
- fd = open(lock_path, O_CREAT | O_EXCL | O_WRONLY, 0666);
- if (fd < 0)
- die("unable to create new ref-pack file (%s)", strerror(errno));
- atexit(remove_lock_file);
-
+ fd = hold_lock_file_for_update(&packed, git_path("packed-refs"), 1);
cbdata.refs_file = fdopen(fd, "w");
if (!cbdata.refs_file)
die("unable to create ref-pack file structure (%s)",
@@ -103,9 +91,8 @@ int cmd_pack_refs(int argc, const char *
for_each_ref(handle_one_ref, &cbdata);
fsync(fd);
fclose(cbdata.refs_file);
- if (rename(lock_path, result_path) < 0)
+ if (commit_lock_file(&packed) < 0)
die("unable to overwrite old ref-pack file (%s)", strerror(errno));
- lock_path = NULL;
if (cbdata.prune)
prune_refs(cbdata.ref_to_prune);
return 0;
--
1.4.2.3.gd1e9e
^ permalink raw reply related
* Re: [PATCH v2] http/ftp: optionally ask curl to not use EPSV command
From: Jakub Narebski @ 2006-10-03 9:11 UTC (permalink / raw)
To: git
In-Reply-To: <20060929001044.GL10617@sashak.voltaire.com>
Sasha Khapyorsky wrote:
> If http.noEPSV config variable is defined and true, or if
> GIT_CURL_FTP_NO_EPSV environment variable is defined, disable using
> of EPSV ftp command (PASV will be used instead). This is helpful with
> some "poor" ftp servers which does not support EPSV mode.
Why the name is http.noEPSV, not ftp.noEPSV (or curl.noEPSV)?
Just curious.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* pull-fetch-param.txt (was Re: [PATCH] escape tilde in Documentation/git-rev-parse.txt)
From: Stefan Richter @ 2006-10-03 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vven1rfpj.fsf@assigned-by-dhcp.cox.net>
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.
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
Here is another fix that works with asciidoc 8.0.0:
`\+?<src>:<dst>`; that is, an optional plus `+`, followed
Results in
----8<----
<refspec>
The canonical format of a <refspec> parameter is +?<src>:<dst>;
that is, an optional plus +, followed by the source ref, fol-
lowed 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----
Does the backslash notation work with asciidoc 7?
--
Stefan Richter
-=====-=-==- =-=- ---==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Junio C Hamano @ 2006-10-03 9:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Luben Tuikov, git
In-Reply-To: <200610031018.40273.jnareb@gmail.com>
BTW,
- why do we have shortlog and log twice in the top navigation
bar in commit view (a=commit)?
- 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
* [PATCH] gitweb: prepare for repositories with packed refs.
From: Junio C Hamano @ 2006-10-03 9:36 UTC (permalink / raw)
To: git
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.
Also factor out two places that checked if the repository can be
exported with similar code into a call to a new function,
check_export_ok.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is to fix a real breakage (iow, not a throw-away patch).
gitweb/gitweb.perl | 26 ++++++++++++++++++++------
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 55d1b2c..671a4e6 100644
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -180,6 +180,22 @@ sub feature_pickaxe {
return ($_[0]);
}
+# checking HEAD file with -e is fragile if the repository was
+# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
+# and then pruned.
+sub check_head_link {
+ my ($dir) = @_;
+ my $headfile = "$dir/HEAD";
+ return ((-e $headfile) ||
+ (-l $headfile && readlink($headfile) =~ /^refs\/heads\//));
+}
+
+sub check_export_ok {
+ my ($dir) = @_;
+ return (check_head_link($dir) &&
+ (!$export_ok || -e "$dir/$export_ok"));
+}
+
# rename detection options for git-diff and git-diff-tree
# - default is '-M', with the cost proportional to
# (number of removed files) * (number of new files).
@@ -212,7 +228,7 @@ our $project = $cgi->param('p');
if (defined $project) {
if (!validate_pathname($project) ||
!(-d "$projectroot/$project") ||
- !(-e "$projectroot/$project/HEAD") ||
+ !check_head_link("$projectroot/$project") ||
($export_ok && !(-e "$projectroot/$project/$export_ok")) ||
($strict_export && !project_in_list($project))) {
undef $project;
@@ -289,7 +305,7 @@ sub evaluate_path_info {
# find which part of PATH_INFO is project
$project = $path_info;
$project =~ s,/+$,,;
- while ($project && !-e "$projectroot/$project/HEAD") {
+ while ($project && !check_head_link("$projectroot/$project")) {
$project =~ s,/*[^/]*$,,;
}
# validate project
@@ -816,8 +832,7 @@ sub git_get_projects_list {
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
- if (-e "$projectroot/$subdir/HEAD" && (!$export_ok ||
- -e "$projectroot/$subdir/$export_ok")) {
+ if (check_export_ok("$projectroot/$subdir")) {
push @list, { path => $subdir };
$File::Find::prune = 1;
}
@@ -838,8 +853,7 @@ sub git_get_projects_list {
if (!defined $path) {
next;
}
- if (-e "$projectroot/$path/HEAD" && (!$export_ok ||
- -e "$projectroot/$path/$export_ok")) {
+ if (check_export_ok("$projectroot/$path")) {
my $pr = {
path => $path,
owner => decode("utf8", $owner, Encode::FB_DEFAULT),
--
1.4.2.3.gd1e9e
^ 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