* Re: [PATCH 3/6] revert: fix buffer overflow in insn sheet parser
From: Junio C Hamano @ 2011-10-20 17:15 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Git List, Christian Couder
In-Reply-To: <20111020090912.GA21471@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Looks good, except I would explain it differently, to avoid referring
> to hypothetical implementation details ("What buffer overflow?"):
>
> test: git cherry-pick --continue should cope with long object names
>
> A naive implementation that uses a commit-id-shaped buffer
> to store the word after "pick" in .git/sequencer/todo lines
> would crash often. Our implementation is not so naive, but
> add a test anyway to futureproof it.
>
> Or:
>
> test: make sure the "cherry-pick --continue" buffer overflow doesn't come back
>
> Before commit ..., "git cherry-pick --continue" would overflow
> under ... circumstance. Add a test to make sure it doesn't
> happen again.
I doubt you would need any of that.
You can just explain the commit that stops copying the lines into a
private, fixed buffer a bit better (e.g. "such copying is not just
wasteful but is wrong by unnecessary placing an artificial limit on the
line length"), and say "Incidentally, this fixes a bug in the earlier
round of this series that failed to read lines that are too long to fit on
the buffer, demonstrated by the test added by this patch", or something.
Then the additional test can become part of the patch that corrects the
parsing logic, no?
^ permalink raw reply
* Re: [PATCH 3/6] revert: fix buffer overflow in insn sheet parser
From: Jonathan Nieder @ 2011-10-20 18:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Git List, Christian Couder
In-Reply-To: <7vmxcva8k1.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
[...]
> Then the additional test can become part of the patch that corrects the
> parsing logic, no?
Yes, that works, too. All I was trying to say was that the
description in the patch I quoted didn't make sense to me, since it
included a mention of a buffer overflow without giving any explanation
of what it was talking about. I don't actually care in this case
whether it is fixed by mentioning which patch this is testing the fix
from or by squashing the two patches (though the latter certainly
seems reasonable).
Incidentally, Ram might wonder why I fuss so much about commit
messages. It's actually very simple --- I think of them as part of
the code. Suppose someone discovers a regression was introduced by
such-and-such part of the patch 1.7.7 -> 1.7.8, but at first glance it
is not clear whether that code change was supposed to have any effect
on the behavior of the code at all. Such a person is likely to make
mistakes in fixing it, right? So after getting the right behavior,
patch authors spend a few extra minutes to make sure the code is
intuitive to humans, too, and this includes making sure the rationale
description is clear.
Just like the code for the computer, this is very much something that
isn't always going to be right the first time and sometimes takes some
debugging. So, sorry for the fuss, but I hope it helps.
Jonathan
^ permalink raw reply
* Re* [IGNORETHIS/PATCH] Choosing the sha1 prefix of your commits
From: Junio C Hamano @ 2011-10-20 18:36 UTC (permalink / raw)
To: Jeff King; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing List
In-Reply-To: <20111020071356.GA14945@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It's not that the commit is bad or the source of problems. My point is
> that the assumption that commit messages are NUL-terminated has been
> there for a really long time, so there are lots of spots in the code
> that sloppily run string functions on them. Every one of those needs to
> be found and fixed (e.g., I remember seeing this in
> for-each-ref.c:find_subpos recently).
>
> It's not impossible, of course, or even really that hard. It's just a
> giant pain, and I wonder if the effort is worth it.
True.
It probably is not worth it for most applications, but this fix-up to a
fairly recent one is worth doing, I would suspect.
-- >8 --
Subject: parse_signed_commit: really use the entire commit log message
... even beyond the first NUL in the buffer, when checking the commit
against the detached signature in the header.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
commit.c | 11 +++++------
t/t7510-signed-commit.sh | 21 ++++++++++++++++-----
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/commit.c b/commit.c
index 93045a2..6ec49fa 100644
--- a/commit.c
+++ b/commit.c
@@ -854,28 +854,27 @@ int parse_signed_commit(const unsigned char *sha1,
unsigned long size;
enum object_type type;
char *buffer = read_sha1_file(sha1, &type, &size);
- int in_header, saw_signature = -1;
+ int saw_signature = -1;
char *line;
if (!buffer || type != OBJ_COMMIT)
goto cleanup;
line = buffer;
- in_header = 1;
saw_signature = 0;
- while (*line) {
+ while (line < buffer + size) {
char *next = strchrnul(line, '\n');
if (*next)
next++;
- if (in_header && !prefixcmp(line, gpg_sig_header)) {
+ if (!prefixcmp(line, gpg_sig_header)) {
const char *sig = line + gpg_sig_header_len;
strbuf_add(signature, sig, next - sig);
saw_signature = 1;
} else {
+ if (*line == '\n')
+ next = buffer + size; /* dump the whole remainder */
strbuf_add(payload, line, next - line);
}
- if (*line == '\n')
- in_header = 0;
line = next;
}
cleanup:
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
index 5c7475d..30401ce 100755
--- a/t/t7510-signed-commit.sh
+++ b/t/t7510-signed-commit.sh
@@ -50,11 +50,22 @@ test_expect_success GPG 'show signatures' '
test_expect_success GPG 'detect fudged signature' '
git cat-file commit master >raw &&
- sed -e "s/fourth signed/4th forged/" raw >forged &&
- git hash-object -w -t commit forged >forged.commit &&
- git show --pretty=short --show-signature $(cat forged.commit) >actual &&
- grep "BAD signature from" actual &&
- ! grep "Good signature from" actual
+
+ sed -e "s/fourth signed/4th forged/" raw >forged1 &&
+ git hash-object -w -t commit forged1 >forged1.commit &&
+ git show --pretty=short --show-signature $(cat forged1.commit) >actual1 &&
+ grep "BAD signature from" actual1 &&
+ ! grep "Good signature from" actual1
+'
+
+test_expect_success GPG 'detect fudged signature with NUL' '
+ git cat-file commit master >raw &&
+ cat raw >forged2 &&
+ echo Qwik | tr "Q" "\000" >>forged2 &&
+ git hash-object -w -t commit forged2 >forged2.commit &&
+ git show --pretty=short --show-signature $(cat forged2.commit) >actual2 &&
+ grep "BAD signature from" actual2 &&
+ ! grep "Good signature from" actual2
'
test_done
^ permalink raw reply related
* Re: [PATCH] builtin/pack-objects.c: Fix a printf format compiler warning
From: Dan McGee @ 2011-10-20 18:54 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <4E9F20AD.4020209@ramsay1.demon.co.uk>
On Wed, Oct 19, 2011 at 2:10 PM, Ramsay Jones
<ramsay@ramsay1.demon.co.uk> wrote:
>
> In particular, on systems that define uint32_t as an unsigned long,
> gcc complains as follows:
>
> CC builtin/pack-objects.o
> pack-objects.c: In function `compute_write_order':
> pack-objects.c:600: warning: unsigned int format, uint32_t arg (arg 3)
>
> In order to suppress the warning, we use the C99 format specifier
> macro PRIu32.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
>
> Hi Dan,
>
> If you need to re-roll your pack-objects series (dm/pack-objects-update
> branch in pu), could you please squash this change into your final commit
> 0a8145bd (pack-objects: don't traverse objects unnecessarily, 18-10-2011).
>
> If you don't need to re-roll, then I'm hoping Junio will notice and squash
> this in before it hits next. ;-)
Sorry about that- fixed locally, and if I do need to resend them then
it will be fixed.
-Dan
^ permalink raw reply
* Re: [PATCH 3/6] revert: fix buffer overflow in insn sheet parser
From: Junio C Hamano @ 2011-10-20 18:55 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Git List, Christian Couder
In-Reply-To: <20111020180533.GA5563@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Incidentally, Ram might wonder why I fuss so much about commit
> messages. It's actually very simple --- I think of them as part of
> the code.
And another reason is because I do fuss about them too ;-)
It is easy to tell a good patch from a bad one by just reading the message
without actually reading the patch text itself.
When the log message justifies the cause and the approach in the right
way, the actual patch becomes self evident. Also I often find myself
coming up with a _better_ solution than the patch I originally prepared
while writing the commit log message to explain it, and redoing the patch
text to match the description.
^ permalink raw reply
* Re: Re* [IGNORETHIS/PATCH] Choosing the sha1 prefix of your commits
From: Jeff King @ 2011-10-20 19:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing List
In-Reply-To: <7vehy7a4sf.fsf_-_@alter.siamese.dyndns.org>
On Thu, Oct 20, 2011 at 11:36:48AM -0700, Junio C Hamano wrote:
> It probably is not worth it for most applications, but this fix-up to a
> fairly recent one is worth doing, I would suspect.
>
> -- >8 --
> Subject: parse_signed_commit: really use the entire commit log message
>
> ... even beyond the first NUL in the buffer, when checking the commit
> against the detached signature in the header.
Yeah, that is worth fixing, I think. It's one thing to be a little lazy
in pretty-printing for "git log", but I think signature verification
should be more careful.
Patch itself looks sane to me. There's still some use of str-like
functions, but they would prevent us from even seeing the signature
headers in the first place, so anything with a NUL that high is just
broken and crappy.
I didn't check, but I wonder if fsck does/should check that there is a
proper end-of-header blank line before we hit any NUL.
-Peff
^ permalink raw reply
* [PATCH] git-gui: use a tristate to control the case mode in the searchbar
From: Bert Wesarg @ 2011-10-20 19:27 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Andrew Ardill, git, Bert Wesarg
In-Reply-To: <CAKPyHN0KCwDu2-JXAEk4wAvfOqE3jHY63aG6R9YSOoLoKwWGgQ@mail.gmail.com>
The config is now called gui.search.case and can have the three values:
no/yes/smart. yes is the default.
It also resets the case detection in smart mode, when the entry field was
cleared by the use.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/search.tcl | 24 +++++++++++++++++-------
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/lib/search.tcl b/lib/search.tcl
index 04a316b..ef1e555 100644
--- a/lib/search.tcl
+++ b/lib/search.tcl
@@ -26,11 +26,20 @@ constructor new {i_w i_text args} {
set ctext $i_text
set default_regexpsearch [is_config_true gui.search.regexp]
- set smartcase [is_config_true gui.search.smartcase]
- if {$smartcase} {
+ switch -- [get_config gui.search.case] {
+ no {
set default_casesensitive 0
- } else {
+ set smartcase 0
+ }
+ smart {
+ set default_casesensitive 0
+ set smartcase 1
+ }
+ yes -
+ default {
set default_casesensitive 1
+ set smartcase 0
+ }
}
set history [list]
@@ -157,12 +166,10 @@ method _incrsearch {} {
if {[catch {$ctext index anchor}]} {
$ctext mark set anchor [_get_new_anchor $this]
}
- if {$smartcase} {
- if {[regexp {[[:upper:]]} $searchstring]} {
+ if {$searchstring ne {}} {
+ if {$smartcase && [regexp {[[:upper:]]} $searchstring]} {
set casesensitive 1
}
- }
- if {$searchstring ne {}} {
set here [_do_search $this anchor mlen]
if {$here ne {}} {
$ctext see $here
@@ -175,6 +182,9 @@ method _incrsearch {} {
#$w.ent configure -background lightpink
$w.ent state pressed
}
+ } elseif {$smartcase} {
+ # clearing the field resets the smart case detection
+ set casesensitive 0
}
}
--
1.7.7.759.gfc8c6
^ permalink raw reply related
* [PATCH] git-gui: span widgets over the full file output area in the blame view
From: Bert Wesarg @ 2011-10-20 19:30 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Bert Wesarg
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/blame.tcl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 49eae19..b031e66 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -219,7 +219,8 @@ constructor new {i_commit i_path i_jump} {
eval grid $w_columns $w.file_pane.out.sby -sticky nsew
grid conf \
$w.file_pane.out.sbx \
- -column [expr {[llength $w_columns] - 1}] \
+ -column 0 \
+ -columnspan [expr {[llength $w_columns] + 1}] \
-sticky we
grid columnconfigure \
$w.file_pane.out \
@@ -229,12 +230,14 @@ constructor new {i_commit i_path i_jump} {
set finder [::searchbar::new \
$w.file_pane.out.ff $w_file \
- -column [expr {[llength $w_columns] - 1}] \
+ -column 0 \
+ -columnspan [expr {[llength $w_columns] + 1}] \
]
set gotoline [::linebar::new \
$w.file_pane.out.lf $w_file \
- -column [expr {[llength $w_columns] - 1}] \
+ -column 0 \
+ -columnspan [expr {[llength $w_columns] + 1}] \
]
set w_cviewer $w.file_pane.cm.t
--
1.7.7.759.gfc8c6
^ permalink raw reply related
* [PATCH] git-gui: guitools: add the path in the confirmation dialog for tools which needs one
From: Bert Wesarg @ 2011-10-20 19:32 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Bert Wesarg
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/tools.tcl | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/tools.tcl b/lib/tools.tcl
index 95e6e55..39e08f0 100644
--- a/lib/tools.tcl
+++ b/lib/tools.tcl
@@ -87,8 +87,14 @@ proc tools_exec {fullname} {
return
}
} elseif {[is_config_true "guitool.$fullname.confirm"]} {
- if {[ask_popup [mc "Are you sure you want to run %s?" $fullname]] ne {yes}} {
- return
+ if {[is_config_true "guitool.$fullname.needsfile"]} {
+ if {[ask_popup [mc "Are you sure you want to run %s on file \"%s\"?" $fullname $current_diff_path]] ne {yes}} {
+ return
+ }
+ } else {
+ if {[ask_popup [mc "Are you sure you want to run %s?" $fullname]] ne {yes}} {
+ return
+ }
}
}
--
1.7.7.759.gfc8c6
^ permalink raw reply related
* Re: [PATCH 2v2/2] git-gui: support for diff3 conflict style
From: Bert Wesarg @ 2011-10-20 19:35 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Bert Wesarg
In-Reply-To: <c761e522cce009a70d9131f0a5a1a2fc6aa6d9ac.1301469420.git.bert.wesarg@googlemail.com>
Ping.
On Wed, Mar 30, 2011 at 09:18, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> This adds highlight support for the diff3 conflict style.
>
> The common pre-image will be reversed to --, because it has been removed
> and either replaced with our or their side.
>
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
> ---
>
> Sorry, I had an syntax error in the last version.
>
> git-gui.sh | 3 +++
> lib/diff.tcl | 12 ++++++++++++
> 2 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/git-gui.sh b/git-gui.sh
> index d5c1535..6adcda6 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -3388,6 +3388,9 @@ $ui_diff tag conf d_s- \
> $ui_diff tag conf d< \
> -foreground orange \
> -font font_diffbold
> +$ui_diff tag conf d| \
> + -foreground orange \
> + -font font_diffbold
> $ui_diff tag conf d= \
> -foreground orange \
> -font font_diffbold
> diff --git a/lib/diff.tcl b/lib/diff.tcl
> index 39e4d90..caa4be7 100644
> --- a/lib/diff.tcl
> +++ b/lib/diff.tcl
> @@ -339,6 +339,7 @@ proc start_show_diff {cont_info {add_opts {}}} {
> }
>
> set ::current_diff_inheader 1
> + set ::in_conflict_pre_image 0
> fconfigure $fd \
> -blocking 0 \
> -encoding [get_path_encoding $path] \
> @@ -439,10 +440,21 @@ proc read_diff {fd conflict_size cont_info} {
> {++} {
> set regexp [string map [list %conflict_size $conflict_size]\
> {^\+\+([<>=]){%conflict_size}(?: |$)}]
> + set regexp_pre_image [string map [list %conflict_size $conflict_size]\
> + {^\+\+\|{%conflict_size}(?: |$)}]
> if {[regexp $regexp $line _g op]} {
> set is_conflict_diff 1
> set line [string replace $line 0 1 { }]
> set tags d$op
> + set ::in_conflict_pre_image 0
> + } elseif {[regexp $regexp_pre_image $line]} {
> + set is_conflict_diff 1
> + set line [string replace $line 0 1 { }]
> + set tags d|
> + set ::in_conflict_pre_image 1
> + } elseif ($::in_conflict_pre_image) {
> + set line [string replace $line 0 1 {--}]
> + set tags d_--
> } else {
> set tags d_++
> }
> --
> 1.7.4.2.743.g539ab
>
>
^ permalink raw reply
* [PATCH] git-gui: delegate selection from gutter columns to text output
From: Bert Wesarg @ 2011-10-20 19:45 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Bert Wesarg
Selecting in the gutter columns of the blame view should make no sense,
so delegate any selection action in these columns to the text output
by selecting whole lines there.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
git-gui.sh | 20 ++++++++++++++++++++
lib/blame.tcl | 4 +++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 21033cb..cf5ed79 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2077,6 +2077,26 @@ proc many2scrollbar {list mode sb top bottom} {
foreach w $list {$w $mode moveto $top}
}
+proc delegate_sel_to {w from} {
+ set bind_list [list \
+ <Button-1> \
+ <B1-Motion> \
+ <Double-Button-1> \
+ <Triple-Button-1> \
+ <Shift-Button-1> \
+ <Double-Shift-Button-1> \
+ <Triple-Shift-Button-1> \
+ ]
+
+ foreach seq $bind_list {
+ set script [bind Text $seq]
+ set new_script [string map [list %W $w %x 0 word line] $script]
+ foreach f $from {
+ bind $f $seq "$new_script; break"
+ }
+ }
+}
+
proc incr_font_size {font {amt 1}} {
set sz [font configure $font -size]
incr sz $amt
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 49eae19..9ab0da5 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -210,6 +210,8 @@ constructor new {i_commit i_path i_jump} {
set w_columns [list $w_amov $w_asim $w_line $w_file]
+ delegate_sel_to $w_file [list $w_amov $w_asim $w_line]
+
${NS}::scrollbar $w.file_pane.out.sbx \
-orient h \
-command [list $w_file xview]
@@ -315,7 +317,7 @@ constructor new {i_commit i_path i_jump} {
$i conf -yscrollcommand \
"[list ::searchbar::scrolled $finder]
[list many2scrollbar $w_columns yview $w.file_pane.out.sby]"
- bind $i <Button-1> "
+ bind $i <Button-1> "+
[cb _hide_tooltip]
[cb _click $i @%x,%y]
focus $i
--
1.7.7.759.gfc8c6
^ permalink raw reply related
* Re: Compiling on Windows
From: Vincent van Ravesteijn @ 2011-10-20 21:38 UTC (permalink / raw)
To: Philip Oakley; +Cc: Andrew Ardill, Git MsysGit, git
In-Reply-To: <2015B7F2CEAE4B449EA4EF744F9B8FD9@PhilipOakley>
>> I once wrote a little step-by-step tutorial on how to compile the
>> native Windows Git with MSVC (Express).
>>
>> http://blog.vfrconsultancy.nl/#post0
>
> The blog post filled in a few gaps in the Msysgit README instructions
> about where to place the various downloads described.
I updated the post a little so that it actually works again. I somehow
like to have a real native Windows compilation of Git.
To successfully compile Git, we also need to change
> #include <sys/resource.h>
into
> #include <io.h>
I have seen some communication about this in the past, but nobody cared
enough to fix this.
Shall I sent a patch that adds a file "compat/win32/sys/resource.h"
which just includes "io.h" ? Or is there another more prefered way to
fix this ?
Vincent
^ permalink raw reply
* [PATCH] tests: add missing executable bits
From: Jeff King @ 2011-10-20 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jeff King <peff@peff.net>
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 t/t4051-diff-function-context.sh
mode change 100644 => 100755 t/t9162-git-svn-dcommit-interactive.sh
diff --git a/t/t4051-diff-function-context.sh b/t/t4051-diff-function-context.sh
old mode 100644
new mode 100755
diff --git a/t/t9162-git-svn-dcommit-interactive.sh b/t/t9162-git-svn-dcommit-interactive.sh
old mode 100644
new mode 100755
--
1.7.7.rc1.28.g5dd2ee
^ permalink raw reply
* Re: [PATCH] gitweb: provide a way to customize html headers
From: Lénaïc Huard @ 2011-10-20 22:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201110171357.00278.jnareb@gmail.com>
This allows web sites to add some specific html headers to the pages
generated by gitweb.
The new variable $site_htmlheader can be set to an html snippet that
will be inserted at the end of the <head> section of each
page generated by gitweb.
Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr.eu.org>
---
Le lundi 17 octobre 2011, Jakub Narebski a écrit :
> On Mon, 17 Oct 2011, Lénaïc Huard wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> > > Lénaïc Huard <lenaic@lhuard.fr.eu.org> writes:
> > > > This allows web sites to add some specific html headers to the pages
> > > > generated by gitweb.
> > >
> > > What do you need this for?
> >
> > I want to decorate the gitweb pages with the “Google Analytics” tracking
> > code. In order to do so, today, Google is recommending to add a <script>
> > tag just before the closing </head> tag.
> >
> > https://www.google.com/support/analyticshelp/bin/answer.py?answer=1008080
> > &hl=en
>
> Hmmm... the modern recommendation from both Google and Yahoo is to put
> script tags at the end of HTML, just before closing </body>, which you
> can do nowadays with $site_footer / GITWEB_SITE_FOOTER.
>
> But I guess that analytics script needs to be loaded earlier.
In fact, I used to insert the Google Analytics tracking code before </body>,
but I recently noticed that Google is now recommending to put the html
snippet at the end of the <head> section.
Here is the recommendation from Google:
https://code.google.com/apis/analytics/docs/tracking/asyncTracking.html
From what I understood, the goal of putting the script tags just before
</body> was to avoid to increase the page load time in case of latency of
the remote server serving the js script.
The GA tracking code is now loading the js asynchronously. So, it doesn’t
block the page load anymore. So, the load can be started asap.
> > > > The new variable $site_htmlheader can be set to a filename the
> > > > content of which will be inserted at the end of the <head> section
> > > > of each page generated by gitweb.
> > >
> > > Hmmm... I wonder if a file with html header fragment (which is quite
> > > specific subset of HTML) is a best solution.
> >
> > That’s true. The piece of code to be inserted in <head> is maybe small
> > enough so that we don’t need a file. Maybe $site_htmlheader could
> > contain directly the html snippet to be inserted in the pages?
>
> I think it might be a better solution.
I changed this in the patch attached in this mail. Now the variable should
contain directly the html code to be inserted.
> > > > gitweb/INSTALL | 3 +++
> > >
> > > Nb. there is patch in flight adding gitweb.conf(5) and gitweb(1)
> > > manpages...
> >
> > Ok. So, I’ll update them once a decision will be taken concerning this
> > $site_htmlheader.
>
> You might have to wait a bit till patches containing gitweb.conf(5)
> manpage are merged in, and rebase your patch to add information about
> new config variable not to gitweb/INSTALL, but to
> Documentation/gitweb.conf.txt
I added the documentation to Documentation/gitweb.conf.txt.
But, as I noticed that gitweb/INSTALL still exists and still documents the
old variables, I left the doc of the new one.
Documentation/gitweb.conf.txt | 5 +++++
gitweb/INSTALL | 2 ++
gitweb/Makefile | 2 ++
gitweb/gitweb.perl | 7 +++++++
t/gitweb-lib.sh | 1 +
5 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index 4ca3e27..5e69c2d 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -364,6 +364,11 @@ $site_name::
+
Can be set using the `GITWEB_SITENAME` at build time. Unset by default.
+$site_htmlheader::
+ HTML snippet to be included in the <head> section of each page.
+ Can be set using `GITWEB_SITE_HTMLHEADER` at build time. No default
+ value.
+
$site_header::
Name of a file with HTML to be included at the top of each page.
Relative to the directory containing the 'gitweb.cgi' script.
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index d134ffe..a6a9f06 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -130,6 +130,8 @@ You can specify the following configuration variables when building GIT:
Points to an .html file which is included on the gitweb project
overview page ('projects_list' view), if it exists. Relative to
gitweb.cgi script. [Default: indextext.html]
+ * GITWEB_SITE_HTMLHEADER
+ html snippet to include in the <head> section of each page. [No default]
* GITWEB_SITE_HEADER
Filename of html text to include at top of each page. Relative to
gitweb.cgi script. [No default]
diff --git a/gitweb/Makefile b/gitweb/Makefile
index 1c85b5f..ecfb311 100644
--- a/gitweb/Makefile
+++ b/gitweb/Makefile
@@ -34,6 +34,7 @@ GITWEB_CSS = static/gitweb.css
GITWEB_LOGO = static/git-logo.png
GITWEB_FAVICON = static/git-favicon.png
GITWEB_JS = static/gitweb.js
+GITWEB_SITE_HTMLHEADER =
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
HIGHLIGHT_BIN = highlight
@@ -144,6 +145,7 @@ GITWEB_REPLACE = \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
-e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
-e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
+ -e 's|++GITWEB_SITE_HTMLHEADER++|$(GITWEB_SITE_HTMLHEADER)|g' \
-e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
-e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
-e 's|++HIGHLIGHT_BIN++|$(HIGHLIGHT_BIN)|g'
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 85d64b2..10b118b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -85,6 +85,8 @@ our $home_link_str = "++GITWEB_HOME_LINK_STR++";
our $site_name = "++GITWEB_SITENAME++"
|| ($ENV{'SERVER_NAME'} || "Untitled") . " Git";
+# html snippet to include in the <head> section of each page
+our $site_htmlheader = "++GITWEB_SITE_HTMLHEADER++";
# filename of html text to include at top of each page
our $site_header = "++GITWEB_SITE_HEADER++";
# html text to include at home page
@@ -3879,6 +3881,11 @@ EOF
print "<base href=\"".esc_url($base_url)."\" />\n";
}
print_header_links($status);
+
+ if (defined $site_htmlheader) {
+ print to_utf8($site_htmlheader);
+ }
+
print "</head>\n" .
"<body>\n";
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index 292753f..cfe5d74 100644
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -16,6 +16,7 @@ our \$projectroot = "$safe_pwd";
our \$project_maxdepth = 8;
our \$home_link_str = 'projects';
our \$site_name = '[localhost]';
+our \$site_htmlheader = '';
our \$site_header = '';
our \$site_footer = '';
our \$home_text = 'indextext.html';
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] builtin/pack-objects.c: Fix a printf format compiler warning
From: Junio C Hamano @ 2011-10-21 0:17 UTC (permalink / raw)
To: Ramsay Jones; +Cc: dpmcgee, Junio C Hamano, GIT Mailing-list
In-Reply-To: <4E9F20AD.4020209@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> If you don't need to re-roll, then I'm hoping Junio will notice and squash
> this in before it hits next. ;-)
Will do; thanks, both.
^ permalink raw reply
* Re: [PATCH] gitweb: provide a way to customize html headers
From: Junio C Hamano @ 2011-10-21 0:37 UTC (permalink / raw)
To: Lénaïc Huard; +Cc: Jakub Narebski, git
In-Reply-To: <201110210046.34679.lenaic@lhuard.fr.eu.org>
Lénaïc Huard <lenaic@lhuard.fr.eu.org> writes:
> +GITWEB_SITE_HTMLHEADER =
> GITWEB_SITE_HEADER =
> GITWEB_SITE_FOOTER =
Is it just me or does the inconsistency between the existing two variables
and this new one with a very similar name stand out like a sore something?
It might have been better if GITWEB_SITE_(HEADER|FOOTER) were named with
"_FILE" suffix, but as long as we consider/declare insert_file is the norm
and in-place inclusion of mini-string is an oddball, it is sufficient to
call this GITWEB_SITE_HTML_HEAD_STRING to avoid confusion?
Perhaps GITWEB_SITE_HEADER_STRING and GITWEB_SITE_FOOTER_STRING might turn
out to be useful in the future for in-place inclusion of mini-strings, and
when that happens, you two would thank me for this suggestion ;-)
^ permalink raw reply
* Re: shallow&single-branch clone?
From: Jeff King @ 2011-10-21 1:22 UTC (permalink / raw)
To: Norbert Nemec; +Cc: git
In-Reply-To: <4E9ED108.5020505@native-instruments.de>
On Wed, Oct 19, 2011 at 03:30:48PM +0200, Norbert Nemec wrote:
> Truncating history is done by 'git clone --depth 1', there is not way
> to restrict 'clone' to a single branch (the --branch option still
> downloads all branches and only then chooses something other than
> HEAD as active branch).
>
> The manual sequence
> git init
> git remote add -t master -f origin URL
> git checkout
> allows a clone of a single branch but offers no means to truncate history.
You can do:
git init
git remote add -t master origin URL
git fetch --depth=1
git checkout
But obviously that's not as nice as an option to clone.
> The least intrusive solution would be an additional option to clone,
> perhaps '--branch-only'.
Agreed, that would be better. We might want to make it more flexible,
like:
git clone --fetch=branch1 --fetch=branch2
and then by default choose "-b branch1" since it was mentioned first.
> More user friendly, this options should be on by default when --depth
> is set. After all: who would expect branches to be cloned when the
> history is explicitely truncated?
Yeah, that probably makes sense. If the branches are related, it's
probably not saving much, but if you have unrelated branches, it would
be a nice convenience. OTOH, how would you tell git "no, I really do
want the tip of every branch"?
-Peff
^ permalink raw reply
* git grep --no-index and absolute paths don't work?
From: Bert Wesarg @ 2011-10-21 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Hi,
I'm currently totally confused, that a
git grep --no-index foo /usr/include
does not work. I know that the documentation says "in the current
directory" for the --no-index flag. But this does not work ether:
cd ~; git grep --no-index foo ~/.bashrc
They all fail with 'is outside repository'. Which is for itself vary
misleading, because I intentionally said --no-index.
Any input is appreciate.
Thanks.
Bert
^ permalink raw reply
* Re: [PATCH] gitweb: provide a way to customize html headers
From: Lénaïc Huard @ 2011-10-21 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vmxcv89jl.fsf@alter.siamese.dyndns.org>
This allows web sites to add some specific html headers to the pages
generated by gitweb.
The new variable $site_html_head_string can be set to an html snippet that
will be inserted at the end of the <head> section of each page generated
by gitweb.
Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr.eu.org>
---
Le vendredi 21 octobre 2011, Junio C Hamano a écrit :
> It might have been better if GITWEB_SITE_(HEADER|FOOTER) were named with
> "_FILE" suffix, but as long as we consider/declare insert_file is the norm
> and in-place inclusion of mini-string is an oddball, it is sufficient to
> call this GITWEB_SITE_HTML_HEAD_STRING to avoid confusion?
Indeed, things will be clearer like this.
Documentation/gitweb.conf.txt | 5 +++++
gitweb/INSTALL | 2 ++
gitweb/Makefile | 2 ++
gitweb/gitweb.perl | 7 +++++++
t/gitweb-lib.sh | 1 +
5 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index 4ca3e27..7aba497 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -364,6 +364,11 @@ $site_name::
+
Can be set using the `GITWEB_SITENAME` at build time. Unset by default.
+$site_html_head_string::
+ HTML snippet to be included in the <head> section of each page.
+ Can be set using `GITWEB_SITE_HTML_HEAD_STRING` at build time.
+ No default value.
+
$site_header::
Name of a file with HTML to be included at the top of each page.
Relative to the directory containing the 'gitweb.cgi' script.
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index d134ffe..6d45406 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -130,6 +130,8 @@ You can specify the following configuration variables when building GIT:
Points to an .html file which is included on the gitweb project
overview page ('projects_list' view), if it exists. Relative to
gitweb.cgi script. [Default: indextext.html]
+ * GITWEB_SITE_HTML_HEAD_STRING
+ html snippet to include in the <head> section of each page. [No default]
* GITWEB_SITE_HEADER
Filename of html text to include at top of each page. Relative to
gitweb.cgi script. [No default]
diff --git a/gitweb/Makefile b/gitweb/Makefile
index 1c85b5f..e65fc27 100644
--- a/gitweb/Makefile
+++ b/gitweb/Makefile
@@ -34,6 +34,7 @@ GITWEB_CSS = static/gitweb.css
GITWEB_LOGO = static/git-logo.png
GITWEB_FAVICON = static/git-favicon.png
GITWEB_JS = static/gitweb.js
+GITWEB_SITE_HTML_HEAD_STRING =
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
HIGHLIGHT_BIN = highlight
@@ -144,6 +145,7 @@ GITWEB_REPLACE = \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
-e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
-e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
+ -e 's|++GITWEB_SITE_HTML_HEAD_STRING++|$(GITWEB_SITE_HTML_HEAD_STRING)|g' \
-e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
-e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
-e 's|++HIGHLIGHT_BIN++|$(HIGHLIGHT_BIN)|g'
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 85d64b2..fa9b83b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -85,6 +85,8 @@ our $home_link_str = "++GITWEB_HOME_LINK_STR++";
our $site_name = "++GITWEB_SITENAME++"
|| ($ENV{'SERVER_NAME'} || "Untitled") . " Git";
+# html snippet to include in the <head> section of each page
+our $site_html_head_string = "++GITWEB_SITE_HTML_HEAD_STRING++";
# filename of html text to include at top of each page
our $site_header = "++GITWEB_SITE_HEADER++";
# html text to include at home page
@@ -3879,6 +3881,11 @@ EOF
print "<base href=\"".esc_url($base_url)."\" />\n";
}
print_header_links($status);
+
+ if (defined $site_html_head_string) {
+ print to_utf8($site_html_head_string);
+ }
+
print "</head>\n" .
"<body>\n";
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index 292753f..21d11d6 100644
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -16,6 +16,7 @@ our \$projectroot = "$safe_pwd";
our \$project_maxdepth = 8;
our \$home_link_str = 'projects';
our \$site_name = '[localhost]';
+our \$site_html_head_string = '';
our \$site_header = '';
our \$site_footer = '';
our \$home_text = 'indextext.html';
--
1.7.7
^ permalink raw reply related
* Re: git grep --no-index and absolute paths don't work?
From: Carlos Martín Nieto @ 2011-10-21 7:09 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <CAKPyHN138OZRt_3PT5ChuTpSEuOdybnyAj8Baqr=3OD=y==jgw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Fri, 2011-10-21 at 08:34 +0200, Bert Wesarg wrote:
> Hi,
>
> I'm currently totally confused, that a
>
> git grep --no-index foo /usr/include
>
> does not work. I know that the documentation says "in the current
> directory" for the --no-index flag. But this does not work ether:
The rest of the sentence reads ", not just those tracked by git" which
implies that the files tracked by git are also searched. This requires a
git repository.
>
> cd ~; git grep --no-index foo ~/.bashrc
>
> They all fail with 'is outside repository'. Which is for itself vary
> misleading, because I intentionally said --no-index.
Git is a tool that works on git repositories. Some commands may work
outside of a repository, like ls-remote when given an URL or init (for
obvious reasons) but it's not something that should be expected,
especially for commands that read files from the working tree.
Why are you trying to use git's grep command outside a repository? Why
isn't 'grep -nr foo /usr/include/' good enough?
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Links not working
From: Andy Hartley @ 2011-10-21 7:29 UTC (permalink / raw)
To: git
Hi,
I have been tying to get to the install msysGit link
https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit
for about a week now. The page load fails after about one minute with
connection lost.
This from your http://code.google.com/p/msysgit/ main page.
FYI, Andy.
^ permalink raw reply
* Re: Links not working
From: Frans Klaver @ 2011-10-21 7:46 UTC (permalink / raw)
To: andy; +Cc: git
In-Reply-To: <686C8AC851FB48E78B12E0BB04A66FCF@DracoMain>
On Fri, Oct 21, 2011 at 9:29 AM, Andy Hartley <andy@soon.com> wrote:
> I have been tying to get to the install msysGit link
> https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit
>
> for about a week now. The page load fails after about one minute with
> connection lost.
kernel.org has been down for over a month. It's been coming back to
life over the last week, but only very slowly. I don't know when
git.wiki.kernel.org will be available again though.
Cheers,
Frans
^ permalink raw reply
* Re: Tracking cherry picks
From: Jonathan Nieder @ 2011-10-21 9:52 UTC (permalink / raw)
To: Phillip Susi; +Cc: git, Kirill Likhodedov, Ramkumar Ramachandra
In-Reply-To: <4EA02E6C.2040608@cfl.rr.com>
Hi,
Phillip Susi wrote:
> Sometimes a bug is found and the fix needs applied to multiple
> branches. I would like to be able to list what branches the fix has been
> applied to to validate that it went in everywhere it was needed, but after
> cherry-picking the fix from master to the stable branches, the SHA1 of the
> commit is different, and so git branch --contains does not think the commit
> was applied to each of the stable branches.
If you base the fix on the oldest commit you think you might ever want to
apply it to, then you can reuse the same bugfix commit in all branches.
See gitworkflows(7) for more on this.
Hope that helps, and good luck,
Jonathan
^ permalink raw reply
* Re: Compiling on Windows
From: Erik Faye-Lund @ 2011-10-21 11:41 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: Philip Oakley, Andrew Ardill, Git MsysGit, git
In-Reply-To: <4EA094D2.7050807@lyx.org>
On Thu, Oct 20, 2011 at 11:38 PM, Vincent van Ravesteijn <vfr@lyx.org> wrote:
>
>>> I once wrote a little step-by-step tutorial on how to compile the native
>>> Windows Git with MSVC (Express).
>>>
>>> http://blog.vfrconsultancy.nl/#post0
>>
>> The blog post filled in a few gaps in the Msysgit README instructions
>> about where to place the various downloads described.
>
> I updated the post a little so that it actually works again. I somehow like
> to have a real native Windows compilation of Git.
Git for Windows is a "real native Windows compilation of Git". You
don't need a MSVC-compiled binary for that.
> To successfully compile Git, we also need to change
>>
>> #include <sys/resource.h>
>
> into
>>
>> #include <io.h>
>
> I have seen some communication about this in the past, but nobody cared
> enough to fix this.
>
There's been some patches dealing with this recently on the msysgit
mailing list. Look for the patches prefixed with "MSVC" in Karsten
Blees' Unicode series. They will be kicked out of the next iteration
of the Unicode series, but if you want to pick them up, clean up the
issues pointed out and re-submit them, that'd be very welcome.
> Shall I sent a patch that adds a file "compat/win32/sys/resource.h" which
> just includes "io.h" ? Or is there another more prefered way to fix this ?
I would prefer <io.h> to be included from compat/msvc.h instead,
because <io.h> isn't a <sys/resource.h> replacement.
As for the missing <sys/resource.h>, I'm not so sure. We don't have
<sys/resource.h> in msysGit either, and I personally don't like the
whole adding-stub-headers approach too much, but it does seem to be
the precedence set for the MSVC-build...
In general I'd say that no-one have worked the MSVC-support in a
while, patches would be welcome :)
^ permalink raw reply
* Re: Links not working
From: John Szakmeister @ 2011-10-21 11:52 UTC (permalink / raw)
To: andy; +Cc: git
In-Reply-To: <686C8AC851FB48E78B12E0BB04A66FCF@DracoMain>
On Fri, Oct 21, 2011 at 3:29 AM, Andy Hartley <andy@soon.com> wrote:
> Hi,
>
> I have been tying to get to the install msysGit link
> https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit
>
> for about a week now. The page load fails after about one minute with
> connection lost.
>
> This from your http://code.google.com/p/msysgit/ main page.
You might find GitHub's page useful in the meantime:
<http://help.github.com/win-set-up-git/>
-John
^ 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