Git development
 help / color / mirror / Atom feed
* 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: Remove redundant "commit" link from shortlog
From: Jakub Narebski @ 2006-10-06 15:08 UTC (permalink / raw)
  To: git
In-Reply-To: <20061006135508.GO20017@pasky.or.cz>

Petr Baudis 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

By the way, commitdiff view in this case also looks strange.
I think that simplyfying the git_difftree_body went too far,
Luben.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply

* Re: [PATCH] Remove bashism from t3210-pack-refs.sh
From: Jakub Narebski @ 2006-10-06 15:05 UTC (permalink / raw)
  To: git
In-Reply-To: <81b0412b0610060635n51482e71wab02f9a11be4e619@mail.gmail.com>

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.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply

* [PATCH] Show snapshot link in shortlog only if have_snapsho
From: Petr Baudis @ 2006-10-06 13:57 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <eft97f$un0$3@sea.gmane.org>

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 gitweb/gitweb.perl |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5c7d95b..bcb41cc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2098,8 +2098,10 @@ sub git_shortlog_body {
 		print "</td>\n" .
 		      "<td class=\"link\">" .
 		      $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
-		      $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree") . " | " .
-		      $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
+		      $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
+		if (gitweb_have_snapshot()) {
+			print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
+		}
 		print "</td>\n" .
 		      "</tr>\n";
 	}

^ permalink raw reply related

* Re: [PATCH] gitweb: Remove redundant "commit" link from shortlog
From: Petr Baudis @ 2006-10-06 13:55 UTC (permalink / raw)
  To: Luben Tuikov; +Cc: git
In-Reply-To: <20060928234840.25950.qmail@web31809.mail.mud.yahoo.com>

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

-- 
				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: Petr Baudis @ 2006-10-06 13:50 UTC (permalink / raw)
  To: Luben Tuikov; +Cc: Jakub Narebski, git
In-Reply-To: <20061002201256.89409.qmail@web31809.mail.mud.yahoo.com>

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?

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.

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.

As of now, gitweb will not handle any filenames containing those three
characters properly because of now.

-- 
				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: Alex Riesen @ 2006-10-06 13:35 UTC (permalink / raw)
  To: Dennis Stosberg; +Cc: git
In-Reply-To: <20061006091054.15209.35068.stgit@leonov.stosberg.net>

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.

^ permalink raw reply

* Re: perhaps time to remove git_blame from gitweb, and git-annotate?
From: Johannes Schindelin @ 2006-10-06 13:07 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Luben Tuikov, Petr Baudis, Jakub Narebski, Ryan Anderson,
	Martin Langhoff, Martyn Smith, Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <7vu02jfaec.fsf_-_@assigned-by-dhcp.cox.net>

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.

Ciao,
Dscho

^ permalink raw reply

* Re: gitweb: using quotemeta
From: Jakub Narebski @ 2006-10-06 12:38 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vven1syg0.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:
> 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';
>         }

I'd rather add (and use) separate subroutine for quoting/escaping
values in HTTP headers, or to be more exact for the filename part
of HTTP header "Content-Disposition:". This way if we decide to
not replace all characters outside US-ASCII in suggested filename
to save with '?', but only qoublequote '"' and linefeed '\n' characters,
or even implement RFC 2047 to do the encoding (of course if browsers
can read it), we could do this in one place. 

How such a subroutine should be named? esc_http? esc_header or esc_hdr?
esc_http_header? Any other ideas?
-- 
Jakub Narebski
Poland

^ permalink raw reply

* Re: Unresolved issues #4
From: Jakub Narebski @ 2006-10-06 10:56 UTC (permalink / raw)
  To: git
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]

It did produce two workflows: the original "build time"
by A Large Angry SCM/Gitzilla, which I think is/will be
available at http://git.rsbx.net/Notes/Git_Subprojects.txt
and second using linked objects and refs. Both I think not
quite finished; perhaps some of the code could be put
in 'pu'.

Perhaps to be added to Subpro.txt in 'todo' branch,
and/or to git wiki...

> 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. 

> From: Josh Triplett <josh@freedesktop.org>
> Message-ID: <451A30E4.50801@freedesktop.org>
> 
> git-split

Should be git-split-hierarchy or git-split-by-directory
I think. We could have also git-split-history, which would
split current history into archive repository, and active
repository with archive repository grafted in; or add to
archive repository if it exists, regraft active (current work)
repository and prune below new grafts. 

> [jc: no response to the initial review comments]

It is "done once" problem, and usable only for some repositories,
so perhaps this is the cause of not many responses.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply

* [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Jakub Narebski @ 2006-10-06 10:31 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac4qs43g.fsf@assigned-by-dhcp.cox.net>

Rename $githelp_url and $githelp_label to $logo_url and $logo_label to
be more obvious what they refer to; while at it add commented out
previous contents (git documentation at kernel.org). Add comment about
logo size.

Use $cgi->a(...) to generate Git logo link; it automatically escapes
attribute values when it is needed.  Escape href attribute using
esc_url instead of (incorrect!) esc_html.

Move styling of git logo <img> element from "style" attribute to CSS
via setting class to "logo".  Perhaps we should set it by id rather
than by class.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:

>>> +             "<a href=\"" . esc_html($githelp_url) .
>>> +             "\" title=\"" . esc_html($githelp_label) .
>>> +             "\">" .
>>
>> Why not use $cgi->a_begin({-href=>esc_param($githelp_url),
>> -title=>$githelp_label}); or just plain $cgi->a and $cgi->img?
>
> Be my guest and send in a proper patch please.
>
> I was merely demonstrating my preference on how definition of
> default values and actual use of them are separated.

And here it is. By the way, esc_html was incorrect, I think.

 gitweb/gitweb.css  |    5 +++++
 gitweb/gitweb.perl |   17 +++++++++--------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 668e69a..3f62b6d 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -16,6 +16,11 @@ a:hover, a:visited, a:active {
 	color: #880000;
 }
 
+img.logo {
+	float: right;
+	border-width: 0px;
+}
+
 div.page_header {
 	height: 25px;
 	padding: 8px;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3320069..a966f9f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -46,13 +46,16 @@ our $home_text = "++GITWEB_HOMETEXT++";
 
 # URI of default stylesheet
 our $stylesheet = "++GITWEB_CSS++";
-# URI of GIT logo
+# URI of GIT logo (72x27 size)
 our $logo = "++GITWEB_LOGO++";
 # URI of GIT favicon, assumed to be image/png type
 our $favicon = "++GITWEB_FAVICON++";
 
-our $githelp_url = "http://git.or.cz/";
-our $githelp_label = "git homepage";
+# URI and label (title) of GIT logo link
+#our $logo_url = "http://www.kernel.org/pub/software/scm/git/docs/";
+#our $logo_label = "git documentation";
+our $logo_url = "http://git.or.cz/";
+our $logo_label = "git homepage";
 
 # source of projects list
 our $projects_list = "++GITWEB_LIST++";
@@ -1376,11 +1379,9 @@ EOF
 	print "</head>\n" .
 	      "<body>\n" .
 	      "<div class=\"page_header\">\n" .
-	      "<a href=\"" . esc_html($githelp_url) .
-	      "\" title=\"" . esc_html($githelp_label) .
-	      "\">" .
-	      "<img src=\"$logo\" width=\"72\" height=\"27\" alt=\"git\" style=\"float:right; border-width:0px;\"/>" .
-	      "</a>\n";
+	      $cgi->a({-href => esc_url($logo_url),
+	               -title => $logo_label},
+	              qq(<img src="$logo" width="72" height="27" alt="git" class="logo"/>));
 	print $cgi->a({-href => esc_url($home_link)}, $home_link_str) . " / ";
 	if (defined $project) {
 		print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
-- 
1.4.2.1

^ permalink raw reply related

* Re: [PATCH] Add default values for --window and --depth to the docs
From: Junio C Hamano @ 2006-10-06 10:05 UTC (permalink / raw)
  To: Dennis Stosberg; +Cc: git
In-Reply-To: <20061006091503.16069.36227.stgit@leonov.stosberg.net>

Thanks, as always.

^ permalink raw reply

* Re: [PATCH 5/6] git-blame --porcelain
From: Junio C Hamano @ 2006-10-06  9:59 UTC (permalink / raw)
  To: Luben Tuikov; +Cc: git
In-Reply-To: <20061006002904.24024.qmail@web31814.mail.mud.yahoo.com>

Luben Tuikov <ltuikov@yahoo.com> writes:

> BTW, I would've chosen to print the line number of the original file
> first, followed by the line number of the final (this) file followed
> by the number of lines in this group of the final (this) file:

Swapped them and trivially adjusted [6/6] for this change.  The
result is found in "pu".

^ permalink raw reply

* [PATCH] Add default values for --window and --depth to the docs
From: Dennis Stosberg @ 2006-10-06  9:15 UTC (permalink / raw)
  To: git

Currently, you actually have to read the source to find out the
default values. While at it, fix two typos and suggest that these
options actually take a parameter in git-pack-objects.txt.

Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---

 Documentation/git-pack-objects.txt |    7 ++++---
 Documentation/git-repack.txt       |    3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index d4661dd..f52e8fa 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -71,11 +71,11 @@ base-name::
 --all::
 	This implies `--revs`.  In addition to the list of
 	revision arguments read from the standard input, pretend
-	as if all refs under `$GIT_DIR/refs` are specifed to be
+	as if all refs under `$GIT_DIR/refs` are specified to be
 	included.
 
---window and --depth::
-	These two options affects how the objects contained in
+--window=[N], --depth=[N]::
+	These two options affect how the objects contained in
 	the pack are stored using delta compression.  The
 	objects are first internally sorted by type, size and
 	optionally names and compared against the other objects
@@ -84,6 +84,7 @@ base-name::
 	it too deep affects the performance on the unpacker
 	side, because delta data needs to be applied that many
 	times to get to the necessary object.
+	The default value for both --window and --depth is 10.
 
 --incremental::
 	This flag causes an object already in a pack ignored
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 49f7e0a..d2eaa09 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -57,13 +57,14 @@ OPTIONS
         `git update-server-info`.
 
 --window=[N], --depth=[N]::
-	These two options affects how the objects contained in the pack are
+	These two options affect how the objects contained in the pack are
 	stored using delta compression. The objects are first internally
 	sorted by type, size and optionally names and compared against the
 	other objects within `--window` to see if using delta compression saves
 	space. `--depth` limits the maximum delta depth; making it too deep
 	affects the performance on the unpacker side, because delta data needs
 	to be applied that many times to get to the necessary object.
+	The default value for both --window and --depth is 10.
 
 
 Author

^ permalink raw reply related

* [PATCH] Remove bashism from t3210-pack-refs.sh
From: Dennis Stosberg @ 2006-10-06  9:10 UTC (permalink / raw)
  To: git

This bashism makes the test fail if /bin/sh is not bash.

Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---

 t/t3210-pack-refs.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
index f31e79c..ca5bd49 100755
--- a/t/t3210-pack-refs.sh
+++ b/t/t3210-pack-refs.sh
@@ -23,7 +23,7 @@ SHA1=
 test_expect_success \
     'see if git show-ref works as expected' \
     'git-branch a &&
-     SHA1=$(< .git/refs/heads/a) &&
+     SHA1=`cat .git/refs/heads/a` &&
      echo "$SHA1 refs/heads/a" >expect &&
      git-show-ref a >result &&
      diff expect result'

^ permalink raw reply related

* Re: [PATCH] gitweb: Decode long title for link tooltips
From: Jakub Narebski @ 2006-10-06  8:54 UTC (permalink / raw)
  To: git
In-Reply-To: <87r6xrvi0g.wl@mail2.atmark-techno.com>

Yasushi SHOJI wrote:

[...]]
> Subject: [PATCH] gitweb: refactor decode() for utf8 conversion
> 
> we already had a few place using decode() to convert perl internal
> encode to utf8.  added a new thin wrapper to do just that.
> 
> Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>

What happened to this patch? Dropped or omitted by mistake?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply

* Re: [PATCH] gitweb: blame: Minimize vertical table row padding
From: Jakub Narebski @ 2006-10-06  7:45 UTC (permalink / raw)
  To: git
In-Reply-To: <20061005203031.33938.qmail@web31814.mail.mud.yahoo.com>

Luben Tuikov wrote:

> Minimize vertical table row padding for blame only.  I
> discovered this while having the browser's blame output
> right next to my editor's window, only to notice how much
> vertically stretched the blame output was.
> 
> Blame most likely shows source code and is in this way
> more "spartan" than the rest of the tables gitweb shows.
> 
> This patch makes the blame table more vertically compact,
> thus being closer to what you'd see in your editor's window,
> as well as reusing more window estate to show more
> information (which in turn minimizes scrolling).

Perhaps we should change blame output from table based to div
block based, like ordinary "blob" view, hmmm...?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply

* Re: [PATCH] gitweb: Do not print "log" and "shortlog" redundantly in commit view
From: Jakub Narebski @ 2006-10-06  7:44 UTC (permalink / raw)
  To: git
In-Reply-To: <20061005192257.50209.qmail@web31809.mail.mud.yahoo.com>

Luben Tuikov wrote:

> Do not print "log" and "shortlog" redundantly in commit
> view.  This is passed into the $extra argument of
> git_print_page_nav from git_commit, but git_print_page_nav
> prints "log" and "shortlog" already with the same head.
> 
> Noticed by Junio.
> 
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>

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.

So while "snapshot" link has it's place in top navigation bar
(but by modyfying git_print_page_nav subroutine, not by adding it
by hand), "history" for example IMHO doesn't; history link should be
present in the bottom part of navigation bar. Perhaps we could
reuse git_print_page_nav for formats, for example blob wiew would have
        blob | _blame_ | _history_ | _raw_ | _HEAD_
while tree view would have
        tree | _snapshot_ | _history_ | _HEAD_
(where _text_ indices link).  Perhaps _snapshot_ in tree view
shouldn't be repeated, although top one might mean snapshot of commitish,
bottom one snapshot of tree.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply

* Re: How to checkout a tag?
From: Jakub Narebski @ 2006-10-06  7:32 UTC (permalink / raw)
  To: git
In-Reply-To: <4524E72D.9030101@shadowen.org>

Andy Whitcroft wrote:

> Jeff Garzik wrote:
>> 
>> Sometimes I receive a kernel patch based off an older version of the
>> kernel, for example a 2.6.18 patch when the current kernel is 2.6.19-rc1.
>> 
>> I would like to create a branch starting at 2.6.18, merge the patch, and
>> then merge up to the current kernel.
>> 
>> How does one check out a tag, or create a branch based on a tag's
>> starting point?
> 
> A tag is a ref like any other:
> 
>       git checkout -b branchname tag

Which is a shortcut for
        git branch branchname tag
        git checkout branchname

You cannot checkout a tag [object], because branch has to be able to move
forward to the new commit when you commit changes,

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

^ permalink raw reply

* Unresolved issues #4
From: Junio C Hamano @ 2006-10-06  6:26 UTC (permalink / raw)
  To: git
In-Reply-To: <7vpseyelcw.fsf@assigned-by-dhcp.cox.net>

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]

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?]

From: Shawn Pearce <spearce@spearce.org>
Message-ID: <20060926215745.GC8177@spearce.org>

git-mirror (reverse of git-push --all).

[jc: any progress?]

From: Junio C Hamano <junkio@cox.net>
Message-ID: <7v7izrzpk2.fsf@assigned-by-dhcp.cox.net>

Deal with rfc2822-invalid author mail address in send-email.

[jc: forgot to apply?]

From: Nicolas Pitre <nico@cam.org>
Subject: [PATCH 8/6] let the GIT native protocol use offsets to delta base when

[jc: applied all but I suspect git-push side hasn't been converted?]

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?]

From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Message-ID: <4523EC14.6070806@s5r6.in-berlin.de>

AsciiDoc 8 does not grok documents written for AsciiDoc 7 out of
the box.

[jc: status?]

From:	Josh Triplett <josh@freedesktop.org>
Message-ID: <451A30E4.50801@freedesktop.org>

git-split

[jc: no response to the initial review comments]

^ permalink raw reply

* [PATCH] ref-log: allow ref@{count} syntax.
From: Junio C Hamano @ 2006-10-06  6:16 UTC (permalink / raw)
  To: git; +Cc: Shawn Pearce

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?

 refs.c      |    6 ++++--
 refs.h      |    2 +-
 sha1_name.c |   44 +++++++++++++++++++++++++++-----------------
 3 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/refs.c b/refs.c
index 305c1a9..d7f4aa5 100644
--- a/refs.c
+++ b/refs.c
@@ -795,7 +795,7 @@ int write_ref_sha1(struct ref_lock *lock
 	return 0;
 }
 
-int read_ref_at(const char *ref, unsigned long at_time, unsigned char *sha1)
+int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *sha1)
 {
 	const char *logfile, *logdata, *logend, *rec, *lastgt, *lastrec;
 	char *tz_c;
@@ -828,7 +828,7 @@ int read_ref_at(const char *ref, unsigne
 		if (!lastgt)
 			die("Log %s is corrupt.", logfile);
 		date = strtoul(lastgt + 1, &tz_c, 10);
-		if (date <= at_time) {
+		if (date <= at_time || cnt == 0) {
 			if (lastrec) {
 				if (get_sha1_hex(lastrec, logged_sha1))
 					die("Log %s is corrupt.", logfile);
@@ -859,6 +859,8 @@ int read_ref_at(const char *ref, unsigne
 			return 0;
 		}
 		lastrec = rec;
+		if (cnt > 0)
+			cnt--;
 	}
 
 	rec = logdata;
diff --git a/refs.h b/refs.h
index 0d4d79e..a57d437 100644
--- a/refs.h
+++ b/refs.h
@@ -39,7 +39,7 @@ extern void unlock_ref(struct ref_lock *
 extern int write_ref_sha1(struct ref_lock *lock, const unsigned char *sha1, const char *msg);
 
 /** Reads log for the value of ref during at_time. **/
-extern int read_ref_at(const char *ref, unsigned long at_time, unsigned char *sha1);
+extern int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *sha1);
 
 /** Returns 0 if target has the right format for a ref. **/
 extern int check_ref_format(const char *target);
diff --git a/sha1_name.c b/sha1_name.c
index ed711f2..e517033 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -249,24 +249,23 @@ static int get_sha1_basic(const char *st
 	static const char *warning = "warning: refname '%.*s' is ambiguous.\n";
 	const char **p, *ref;
 	char *real_ref = NULL;
-	int refs_found = 0, am;
-	unsigned long at_time = (unsigned long)-1;
+	int refs_found = 0;
+	int at, reflog_len;
 	unsigned char *this_result;
 	unsigned char sha1_from_ref[20];
 
 	if (len == 40 && !get_sha1_hex(str, sha1))
 		return 0;
 
-	/* At a given period of time? "@{2 hours ago}" */
-	for (am = 1; am < len - 1; am++) {
-		if (str[am] == '@' && str[am+1] == '{' && str[len-1] == '}') {
-			int date_len = len - am - 3;
-			char *date_spec = xmalloc(date_len + 1);
-			strlcpy(date_spec, str + am + 2, date_len + 1);
-			at_time = approxidate(date_spec);
-			free(date_spec);
-			len = am;
-			break;
+	/* basic@{time or number} format to query ref-log */
+	reflog_len = 0;
+	if (str[len-1] == '}') {
+		for (at = 1; at < len - 1; at++) {
+			if (str[at] == '@' && str[at+1] == '{') {
+				reflog_len = (len-1) - (at+2);
+				len = at;
+				break;
+			}
 		}
 	}
 
@@ -291,11 +290,22 @@ static int get_sha1_basic(const char *st
 	if (warn_ambiguous_refs && refs_found > 1)
 		fprintf(stderr, warning, len, str);
 
-	if (at_time != (unsigned long)-1) {
-		read_ref_at(
-			real_ref,
-			at_time,
-			sha1);
+	if (reflog_len) {
+		/* Is it asking for N-th entry, or approxidate? */
+		int nth, i;
+		unsigned long at_time;
+		for (i = nth = 0; 0 <= nth && i < reflog_len; i++) {
+			char ch = str[at+2+i];
+			if ('0' <= ch && ch <= '9')
+				nth = nth * 10 + ch - '0';
+			else
+				nth = -1;
+		}
+		if (0 <= nth)
+			at_time = 0;
+		else
+			at_time = approxidate(str + at + 2);
+		read_ref_at(real_ref, at_time, nth, sha1);
 	}
 
 	free(real_ref);
-- 
1.4.2.3.gae59

^ permalink raw reply related

* Re: git-send-email w/ headers
From: Junio C Hamano @ 2006-10-06  6:09 UTC (permalink / raw)
  To: Len Brown; +Cc: git
In-Reply-To: <200610060041.56807.len.brown@intel.com>

Len Brown <len.brown@intel.com> writes:

> But the Signed-off-by: line from the original message body has
> now been swallowed up into the message header -- so my mailer
> doesn't display it.

Sorry, what I sent out has worse breakage than not having your
custom header.  It would eat the first paragraph of your message
X-<.

A replacement patch is attached.  If you have already applied
the previous patch, you can hand edit the line that says:

	$header .= join("\n", @xh);

to

	$header .= join("\n", @xh) . "\n";

It forgets to end the last line of the headers with LF.

---

diff --git a/git-send-email.perl b/git-send-email.perl
index 3f50aba..2fd5e87 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -83,7 +83,7 @@ # Constants (essentially)
 my $compose_filename = ".msg.$$";
 
 # Variables we fill in automatically, or via prompting:
-my (@to,@cc,@initial_cc,@bcclist,
+my (@to,@cc,@initial_cc,@bcclist,@xh,
 	$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
 
 # Behavior modification variables
@@ -422,6 +422,9 @@ X-Mailer: git-send-email $gitversion
 		$header .= "In-Reply-To: $reply_to\n";
 		$header .= "References: $references\n";
 	}
+	if (@xh) {
+		$header .= join("\n", @xh) . "\n";
+	}
 
 	if ($smtp_server =~ m#^/#) {
 		my $pid = open my $sm, '|-';
@@ -472,6 +475,7 @@ foreach my $t (@files) {
 
 	my $author_not_sender = undef;
 	@cc = @initial_cc;
+	@xh = ();
 	my $found_mbox = 0;
 	my $header_done = 0;
 	$message = "";
@@ -495,6 +499,9 @@ foreach my $t (@files) {
 						$2, $_) unless $quiet;
 					push @cc, $2;
 				}
+				elsif (/^[-A-Za-z]+:\s+\S/) {
+					push @xh, $_;
+				}
 
 			} else {
 				# In the traditional

^ permalink raw reply related

* Re: activestate perl: Makemaker generates broken Makefiles.
From: Junio C Hamano @ 2006-10-06  4:57 UTC (permalink / raw)
  To: Alex Riesen; +Cc: Git Mailing List, Petr Baudis
In-Reply-To: <81b0412b0610040425j60d0647dk1489d02657379c13@mail.gmail.com>

"Alex Riesen" <raa.lkml@gmail.com> writes:

> Just a heads up. Makefile.PL can't be used. The attached patch removes
> everything perl (sorry, but it'd help someone to get going).

Since we do not have Git.xs anymore, wouldn't it be possible for
us to remove perl/Makefile.PL and have our own perl/Makefile
which does:

 * install Git.pm to $(prefix)/share/git-core/perl (aka GIT_PERL_DIR)

 * see if Error.pm is available on the system, and if not install
   private-Error.pm as Error.pm

to make everybody happy???

^ permalink raw reply

* Re: git-send-email w/ headers
From: Len Brown @ 2006-10-06  4:41 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7viriy9w1q.fsf@assigned-by-dhcp.cox.net>

On Thursday 05 October 2006 19:34, 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?

The good news is that the message received now includes the custom headers
from the original message.

But the Signed-off-by: line from the original message body
has now been swallowed up into the message header -- so my mailer doesn't display it.

thanks,
-Len

Original Message:
From 42f19e47f7e720cce936e4fdbaa979b6d4cf2f13 Mon Sep 17 00:00:00 2001
Message-Id: <42f19e47f7e720cce936e4fdbaa979b6d4cf2f13.1160108957.git.len.brown@intel.com>
From: Len Brown <len.brown@intel.com>
Date: Wed, 4 Oct 2006 01:11:12 -0400
Subject: [PATCH 1/14] test: create junk
Reply-To: Len Brown <lenb@kernel.org>
Organization: Intel Open Source Technology Center

Signed-off-by: Len Brown <len.brown@intel.com>
---
 junk |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/junk b/junk
new file mode 100644
index 0000000..9ecf3cf
--- /dev/null
+++ b/junk
@@ -0,0 +1 @@
+this
--
1.4.2.3.gabd6-dirty

Received Message:

Return-Path: <len.brown@intel.com>
 Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [206.18.177.53])
        by hera.kernel.org (8.13.7/8.13.7) with ESMTP id k964RZPa026442
        for <lenb@kernel.org>; Fri, 6 Oct 2006 04:28:01 GMT
 Received: from localhost.localdomain (c-65-96-213-102.hsd1.ma.comcast.net[65.96.213.102])
          by comcast.net (alnrmhc13) with SMTP
          id <20061006042729b1300l5679e>; Fri, 6 Oct 2006 04:27:30 +0000
 From: Len Brown <len.brown@intel.com>
 To: lenb@kernel.org
 Cc: Len Brown <len.brown@intel.com>
 Subject: [PATCH 1/14] test: create junk
 Date: Fri,  6 Oct 2006 00:30:29 -0400
 Message-Id: <11601090432143-git-send-email-len.brown@intel.com>
 X-Mailer: git-send-email 1.4.2.3.gabd6-dirty
 In-Reply-To: <1160109042971-git-send-email-len.brown@intel.com>
 References: <1160109042971-git-send-email-len.brown@intel.com>
 Message-Id: <42f19e47f7e720cce936e4fdbaa979b6d4cf2f13.1160108957.git.len.brown@intel.com>
 Date: Wed, 4 Oct 2006 01:11:12 -0400
 Reply-To: Len Brown <lenb@kernel.org>
 Organization: Intel Open Source Technology Center
 Signed-off-by: Len Brown <len.brown@intel.com>
 X-Virus-Scanned: ClamAV 0.88.4/1999/Thu Oct  5 17:35:38 2006 on hera.kernel.org
 X-Virus-Status: Clean
 X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,
        FORGED_RCVD_HELO,INVALID_DATE autolearn=no version=3.1.3
 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on hera.kernel.org
 Status: R
 X-Status: NGC
 X-KMail-EncryptionState: 
 X-KMail-SignatureState: 
 X-KMail-MDN-Sent: 
 Content-Type: 
 
---
 junk |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/junk b/junk
new file mode 100644
index 0000000..9ecf3cf
--- /dev/null
+++ b/junk
@@ -0,0 +1 @@
+this
-- 
1.4.2.3.gabd6-dirty

^ permalink raw reply related

* Re: [PATCH] cherry-pick: make -r the default
From: Linus Torvalds @ 2006-10-06  1:20 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vsli245zp.fsf@assigned-by-dhcp.cox.net>



On Thu, 5 Oct 2006, Junio C Hamano wrote:
> 
>    Thanks for reminding.  Does the rationale and warning for -x
>    in the documentation look Ok?

Looks good, thanks.

		Linus

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox