* Re: question about COMMIT_EDITMSG crlf
From: Juanma Barranquero @ 2009-01-14 9:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Frank Li, git
In-Reply-To: <496D91CE.1000504@viscovery.net>
On Wed, Jan 14, 2009 at 08:18, Johannes Sixt <j.sixt@viscovery.net> wrote:
> No, there isn't. But perhaps you can use WordPad instead of Notepad? There
> are reports that this worked.
Or Notepad2:
http://www.flos-freeware.ch/notepad2.html
Juanma
^ permalink raw reply
* Re: .ft tag in man
From: Michael J Gruber @ 2009-01-14 10:11 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Junio C Hamano, bill lam, git
In-Reply-To: <20090114064510.GZ18365@inocybe.teonanacatl.org>
Todd Zullinger venit, vidit, dixit 14.01.2009 07:45:
...
> I began seeing this on Fedora 10. Defining DOCBOOK_XSL_172 fixed
> that issue, but seems to have caused another. :/
>
> For example, in git-diff.1, without DOCBOOK_XSL_172, I see:
>
> .ft C
> $ git diff (1)
> $ git diff --cached (2)
> $ git diff HEAD (3)
> .ft
>
> With DOCBOOK_XSL_172, I get this:
>
> $ git diff ▓fB(3)▓fR
> $ git diff --cached ▓fB(2)▓fR
> $ git diff HEAD ▓fB(3)▓fR
>
> The '.ft' problem is gone, but '\fB' and '\fR' are replaced by '▓fB'
> and '▓fR', respectively. The paragraphs that follow such a list of
> commands show more ugliness:
>
> ⌂sp ▓fB1. ▓fRChanges in the working tree not yet staged for the
> next commit. ⌂br ▓fB2. ▓fRChanges between the index and your
> last commit; what you would be committing if you run "git commit"
> without "-a" option. ⌂br ▓fB3. ▓fRChanges in the working tree
> since your last commit; what you would be committing if you run
> "git commit -a" ⌂br
>
> Defining ASCIIDOC8 seems to have no effect on this problem.
>
>> Perhaps you are using different version of asciidoc/docbook/xmlto
>> toolchain?
>
> On Fedora 10, these are the versions:
>
> asciidoc-8.2.5-2.fc9
> docbook-dtds-1.0-41.fc10
> docbook-style-xsl-1.74.0-4.fc10
> xmlto-0.0.21-2.fc10
>
> Fedora 9 has:
>
> asciidoc-8.2.5-2.fc9
> docbook-dtds-1.0-38.fc9
> docbook-style-xsl-1.73.2-10.fc9
> xmlto-0.0.20-3.fc9
The problem can be seen even in the F10 release packages for git. Shame
on them ;)
When I get back to my F9 box I'll try upgrading those packages one by
one to their F10 versions (hoping dependencies don't connect all of them).
Michael
^ permalink raw reply
* Re: [PATCH next] git-notes: fix printing of multi-line notes
From: Johannes Schindelin @ 2009-01-14 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tor Arne Vestbø, git
In-Reply-To: <7v3afm758u.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 875 bytes --]
Hi,
On Tue, 13 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 13 Jan 2009, Tor Arne Vestbø wrote:
> >
> >> The line length was read from the same position every time,
> >> causing mangled output when printing notes with multiple lines.
> >>
> >> Also, adding new-line manually for each line ensures that we
> >> get a new-line between commits, matching git-log for commits
> >> without notes.
> >>
> >> Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
> >> ---
> >
> > Patch looks good, so
> >
> > Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > For extra browny points, you could add a test with multi-line notes.
>
> Yeah, not just "extra", having tests is a good way to make sure a new
> feature like this evolves healthily.
Oh, and of course I meant "brownie"...
Ducks,
Dscho
^ permalink raw reply
* Re: jgit merge question
From: Johannes Schindelin @ 2009-01-14 10:26 UTC (permalink / raw)
To: David Birchfield; +Cc: git
In-Reply-To: <4EDE3D74-CEA3-473C-ADD1-03B79AAB9EDF@asu.edu>
Hi,
On Wed, 14 Jan 2009, David Birchfield wrote:
> I have been working with the JGit library and with the pgm files and
> other documentation I have been able to implement most of the basic
> functions that I need for my testing application - including fetch.
> This is great! However, I have not been able to successfully implement
> the merge function with JGit. There is some reference to this in the
> mail archive, but I cannot find any of the merge code that is referenced
> in the distribution.
You mean
http://thread.gmane.org/gmane.comp.version-control.git/100524/focus=100589
?
Yes, it has not been implemented, basically because it needs a diff
implementation, and I constantly run out of time working on it. I have
something that works, but needs lots of improvements to be usable
(basically, it has to avoid deep recursion depths).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Noted that vi is the final choice of editor in git help commit
From: Adeodato Simó @ 2009-01-14 9:55 UTC (permalink / raw)
To: Craig Fratrik; +Cc: git
In-Reply-To: <1231886016-31675-1-git-send-email-cfratrik@gmail.com>
* Craig Fratrik [Tue, 13 Jan 2009 14:33:36 -0800]:
> The editor used to edit the commit log message will be chosen from the
> GIT_EDITOR environment variable, the core.editor configuration variable, the
> -VISUAL environment variable, or the EDITOR environment variable (in that
> -order).
> +VISUAL environment variable, the EDITOR environment variable, or finally 'vi'
> +(in that order).
May I suggest:
The editor used to edit the commit log message will be chosen from the
GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
-order).
+order). If none of those are set, "vi" will be used.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Fix nested links problem with ref markers
From: Jakub Narebski @ 2009-01-14 10:39 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0901131956s7f441c38o3a0b1e5f456a3cd3@mail.gmail.com>
On Wed, 14 Jan 2009, Giuseppe Bilotta wrote:
> On Tue, Jan 13, 2009 at 7:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 13 Jan 2009, Giuseppe Bilotta wrote:
[...]
>>> The float thing was the second suggestion I was given on www-style.
>>
>> What was the first suggestion? And what is www-style?
>
> The first suggestion was to just leave things as they are. www-style
> is www-style@w3c.org, the CSS mailing list of the W3C
Thanks.
>>> Can you provide a patch I can apply to my tree for testing to see how
>>> it comes up?
>>
>> Here it is. Note that CSS could be I think reduced. The size of
>> gitweb.perl changes is affected by changing calling convention for
>> git_print_header_html subroutine.
>
> It's funny, I was working on a very similar patch myself a couple of
> days ago, but couldn't get the horizontal filler after the link to
> work properly, which is why I asked on www-style.
>
> I'll test your patch and let you know.
I am checking 'log' view of git repository; it should have enough
ref markers to test this issue.
It works also in Konqueror 3.5.3-0.2.fc4...
>> There is also strange artifact at least in Mozilla 1.17.2: if I hover
>> over ref marker, the subject (title) gets darker background. Curious...
>
> Might be some kind of bug with the capturing vs bubbling phase.
...but the same artifact can be seen too. Also I am not entirely
pleased with the way things behave on mouseover. It is a pity that
you cannot style element using CSS2.1 based on the pseudo-class :hover
of descendant element, or/and pseudo-class of sibling element, which
nevertheless overlays given element.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 1/3] git-daemon: single-line logs
From: Jan Engelhardt @ 2009-01-14 10:48 UTC (permalink / raw)
To: git
parent v1.6.1
git-daemon: single-line logs
Having just a single line per connection attempt, much like Apache
httpd2 access logs, makes log parsing much easier, especially when
just glancing over it non-automated.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -295,12 +295,13 @@ static int git_daemon_config(const char
return 0;
}
-static int run_service(char *dir, struct daemon_service *service)
+static int run_service(char *dir, struct daemon_service *service,
+ const char *origin, const char *vhost)
{
const char *path;
int enabled = service->enabled;
- loginfo("Request %s for '%s'", service->name, dir);
+ loginfo("%s->%s %s \"%s\"\n", origin, vhost, service->name, dir);
if (!enabled && !service->overridable) {
logerror("'%s': service not enabled.", service->name);
@@ -507,10 +508,10 @@ static void parse_extra_args(char *extra
static int execute(struct sockaddr *addr)
{
static char line[1000];
+ char addrbuf[256] = "";
int pktlen, len, i;
if (addr) {
- char addrbuf[256] = "";
int port = -1;
if (addr->sa_family == AF_INET) {
@@ -529,7 +530,6 @@ static int execute(struct sockaddr *addr
port = ntohs(sin6_addr->sin6_port);
#endif
}
- loginfo("Connection from %s:%d", addrbuf, port);
setenv("REMOTE_ADDR", addrbuf, 1);
}
else {
@@ -541,10 +541,6 @@ static int execute(struct sockaddr *addr
alarm(0);
len = strlen(line);
- if (pktlen != len)
- loginfo("Extended attributes (%d bytes) exist <%.*s>",
- (int) pktlen - len,
- (int) pktlen - len, line + len + 1);
if (len && line[len-1] == '\n') {
line[--len] = 0;
pktlen--;
@@ -569,7 +565,8 @@ static int execute(struct sockaddr *addr
* Note: The directory here is probably context sensitive,
* and might depend on the actual service being performed.
*/
- return run_service(line + namelen + 5, s);
+ return run_service(line + namelen + 5, s,
+ addrbuf, hostname);
}
}
^ permalink raw reply
* [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname
From: Jan Engelhardt @ 2009-01-14 10:48 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LSU.2.00.0901141147120.16109@fbirervta.pbzchgretzou.qr>
parent v1.6.1
git-daemon: use getnameinfo to resolve hostname
This is much shorter than inet_ntop'ing, and also translated
unresolvable addresses into a string.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -512,25 +512,13 @@ static int execute(struct sockaddr *addr
int pktlen, len, i;
if (addr) {
- int port = -1;
-
- if (addr->sa_family == AF_INET) {
- struct sockaddr_in *sin_addr = (void *) addr;
- inet_ntop(addr->sa_family, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
- port = ntohs(sin_addr->sin_port);
-#ifndef NO_IPV6
- } else if (addr && addr->sa_family == AF_INET6) {
- struct sockaddr_in6 *sin6_addr = (void *) addr;
-
- char *buf = addrbuf;
- *buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
- inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
- strcat(buf, "]");
-
- port = ntohs(sin6_addr->sin6_port);
-#endif
- }
- setenv("REMOTE_ADDR", addrbuf, 1);
+ i = getnameinfo(addr, (addr->sa_family == AF_INET6) ?
+ sizeof(struct sockaddr_in6) : sizeof(struct sockaddr_in),
+ addrbuf, sizeof(addrbuf), NULL, 0, 0);
+ if (i == 0)
+ setenv("REMOTE_ADDR", addrbuf, 1);
+ else
+ unsetenv("REMOTE_ADDR");
}
else {
unsetenv("REMOTE_ADDR");
^ permalink raw reply
* [PATCH 3/3] git-daemon: vhost support
From: Jan Engelhardt @ 2009-01-14 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LSU.2.00.0901141148130.16109@fbirervta.pbzchgretzou.qr>
parent v1.6.1
git-daemon: support vhosts
Since git clients usually send the target hostname in the request
similar to the "Host:" HTTP header, one can do virtual hosting.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -2,6 +2,7 @@
#include "pkt-line.h"
#include "exec_cmd.h"
+#include <stdbool.h>
#include <syslog.h>
#ifndef HOST_NAME_MAX
@@ -21,7 +22,7 @@ static const char daemon_usage[] =
" [--timeout=n] [--init-timeout=n] [--max-connections=n]\n"
" [--strict-paths] [--base-path=path] [--base-path-relaxed]\n"
" [--user-path | --user-path=path]\n"
-" [--interpolated-path=path]\n"
+" [--interpolated-path=path] [--vhost]\n"
" [--reuseaddr] [--detach] [--pid-file=file]\n"
" [--[enable|disable|allow-override|forbid-override]=service]\n"
" [--inetd | [--listen=host_or_ipaddr] [--port=n]\n"
@@ -36,6 +37,7 @@ static int strict_paths;
static int export_all_trees;
/* Take all paths relative to this one if non-NULL */
+static bool enable_vhosting;
static char *base_path;
static char *interpolated_path;
static int base_path_relaxed;
@@ -309,8 +311,18 @@ static int run_service(char *dir, struct
return -1;
}
- if (!(path = path_ok(dir)))
- return -1;
+ if (enable_vhosting) {
+ char vdir[256];
+
+ if (avoid_alias(dir) != 0)
+ return -1;
+ snprintf(vdir, sizeof(vdir), "/%s%s", hostname, dir);
+ if ((path = path_ok(vdir)) == NULL)
+ return -1;
+ } else {
+ if ((path = path_ok(dir)) == NULL)
+ return -1;
+ }
/*
* Security on the cheap.
@@ -1046,6 +1058,10 @@ int main(int argc, char **argv)
make_service_overridable(arg + 18, 0);
continue;
}
+ if (strcmp(arg, "--vhost") == 0) {
+ enable_vhosting = true;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
^ permalink raw reply
* Re: [PATCH] Noted that vi is the final choice of editor in git help commit
From: Michael J Gruber @ 2009-01-14 11:14 UTC (permalink / raw)
To: Adeodato Simó; +Cc: Craig Fratrik, git
In-Reply-To: <20090114095512.GA29927@chistera.yi.org>
Adeodato Simó venit, vidit, dixit 14.01.2009 10:55:
> * Craig Fratrik [Tue, 13 Jan 2009 14:33:36 -0800]:
>
>> The editor used to edit the commit log message will be chosen from the
>> GIT_EDITOR environment variable, the core.editor configuration variable, the
>> -VISUAL environment variable, or the EDITOR environment variable (in that
>> -order).
>> +VISUAL environment variable, the EDITOR environment variable, or finally 'vi'
>> +(in that order).
>
> May I suggest:
>
> The editor used to edit the commit log message will be chosen from the
> GIT_EDITOR environment variable, the core.editor configuration variable, the
> VISUAL environment variable, or the EDITOR environment variable (in that
> -order).
> +order). If none of those are set, "vi" will be used.
>
+order). If none of those are set, "vi" will be used unless TERM is
+unset or set to "dumb".
There is also some special parsing of the value but I don't think it
needs to be advertised. The terminal-less case, on the other hand, may
be relevant for scripters and ssh'ers.
Cheers,
Michael
^ permalink raw reply
* What's cooking in git.git (Jan 2009, #03; Wed, 14)
From: Junio C Hamano @ 2009-01-14 11:32 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The ones marked with '.' do not appear in any of
the branches, but I am still holding onto them.
The topics list the commits in reverse chronological order. The
topics meant to be merged to the maintenance series have "maint-"
in their names.
----------------------------------------------------------------
[New Topics]
* kb/am-directory (Sun Jan 11 22:21:48 2009 -0800) 1 commit
+ git-am: add --directory=<dir> option
This is "third-time-lucky, perhaps?" resurrection. I do not think I'd be
using this very often, but it originated from a real user request.
* jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
- pager: do wait_for_pager on signal death
- refactor signal handling for cleanup functions
- chain kill signals for cleanup functions
* kb/lstat-cache (Tue Jan 13 13:29:08 2009 +0100) 5 commits
- lstat_cache(): introduce clear_lstat_cache() function
- lstat_cache(): introduce invalidate_lstat_cache() function
- lstat_cache(): introduce has_dirs_only_path() function
- lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
- lstat_cache(): more cache effective symlink/directory detection
This is the seventh round; although the author asked me not to bother, I
couldn't resist. I renamed one helper function while reading the patches
and made minor adjustments on styles, but it looked reasonable.
* lh/submodule-tree-traversal (Mon Jan 12 00:45:55 2009 +0100) 3 commits
- builtin-ls-tree: enable traversal of submodules
- archive.c: enable traversal of submodules
- tree.c: add support for traversal of submodules
* jc/maint-format-patch-o-relative (Mon Jan 12 15:18:02 2009 -0800) 1 commit
- Teach format-patch to handle output directory relative to cwd
This was my lunchtime "this may fix it" response to a breakage report. I
haven't really thought things through but my gut feeling is this might
break things for minorities who are accustomed to the existing behaviour,
especially wrt the filenames reported on the standard output.
* lt/maint-wrap-zlib (Wed Jan 7 19:54:47 2009 -0800) 1 commit
+ Wrap inflate and other zlib routines for better error reporting
Needs the "free our memory upon seeing Z_MEM_ERROR and try again" bits
extracted from Shawn's patch on top of this one.
* js/diff-color-words (Sun Jan 11 21:00:58 2009 +0100) 4 commits
- color-words: take an optional regular expression describing words
- color-words: refactor to allow for 0-character word boundaries
- color-words: refactor word splitting and use ALLOC_GROW()
- Add color_fwrite(), a function coloring each line individually
Dscho's series that was done in response to Thomas's original; two agreed
to work together on this codebase.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
. autoconf: Enable threaded delta search when pthreads are supported
I haven't heard neither positive nor negative comments from minority
platforms that might be harmed, but this feels like the right thing to do,
so perhaps the best course of action is to merge this down to 'master' and
see if anybody screams.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
----------------------------------------------------------------
[Actively cooking]
* gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
+ gitweb: suggest name for OPML view
+ gitweb: don't use pathinfo for global actions
* ks/maint-mailinfo-folded (Mon Jan 12 15:22:11 2009 -0800) 2 commits
- mailinfo: 'From:' header should be unfold as well
- mailinfo: correctly handle multiline 'Subject:' header
The author seems to have more updates, but I couldn't extract them from
the e-mail.
* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
+ bash completions: Add the --patience option
+ Introduce the diff option '--patience'
+ Implement the patience diff algorithm
* mv/apply-parse-opt (Fri Jan 9 22:21:36 2009 -0800) 2 commits
+ Resurrect "git apply --flags -" to read from the standard input
+ parse-opt: migrate builtin-apply.
* tr/rebase-root (Fri Jan 2 23:28:29 2009 +0100) 4 commits
+ rebase: update documentation for --root
+ rebase -i: learn to rebase root commit
+ rebase: learn to rebase root commit
+ rebase -i: execute hook only after argument checking
Looked reasonable.
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
----------------------------------------------------------------
[Graduated to "master"]
* nd/grep-assume-unchanged (Sat Dec 27 15:21:03 2008 +0700) 2 commits
+ grep: grep cache entries if they are "assume unchanged"
+ grep: support --no-ext-grep to test builtin grep
* as/maint-shortlog-cleanup (Tue Dec 30 22:01:44 2008 +0100) 1 commit
+ builtin-shortlog.c: use string_list_append(), and don't strdup
unnecessarily
* jc/maint-ls-tree (Wed Dec 31 19:00:50 2008 +0900) 2 commits
+ Document git-ls-tree --full-tree
+ ls-tree: add --full-tree option
* js/bundle-tags (Fri Jan 2 19:08:46 2009 +0100) 1 commit
+ bundle: allow rev-list options to exclude annotated tags
* js/add-not-submodule (Fri Jan 2 19:08:40 2009 +0100) 1 commit
+ git add: do not add files from a submodule
* pb/maint-git-pm-false-dir (Mon Dec 29 01:25:00 2008 +0100) 1 commit
+ Git.pm: correctly handle directory name that evaluates to "false"
* pj/maint-ldflags (Sun Jan 4 21:27:41 2009 -0500) 1 commit
+ configure clobbers LDFLAGS
* fe/cvsserver (Fri Jan 2 16:40:14 2009 +0100) 2 commits
+ cvsserver: change generation of CVS author names
+ cvsserver: add option to configure commit message
* js/maint-bisect-gitk (Fri Jan 2 19:08:00 2009 +0100) 1 commit
+ bisect view: call gitk if Cygwin's SESSIONNAME variable is set
* np/no-loosen-prune-expire-now (Tue Dec 30 14:45:11 2008 -0500) 1 commit
+ objects to be pruned immediately don't have to be loosened
* cb/maint-unpack-trees-absense (Thu Jan 1 21:54:33 2009 +0100) 3 commits
+ unpack-trees: remove redundant path search in verify_absent
+ unpack-trees: fix path search bug in verify_absent
+ unpack-trees: handle failure in verify_absent
* mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
+ git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
OS X
* mh/cherry-default (Thu Jan 1 22:56:29 2009 +0100) 2 commits
+ Documentation: clarify which parameters are optional to git-cherry
+ git-cherry: make <upstream> parameter optional
Some of the above will still need to be downmerged to respective
maintenance branches after they are widely used on 'master'.
----------------------------------------------------------------
[Will merge to "master" soon]
* mh/maint-commit-color-status (Thu Jan 8 19:53:05 2009 +0100) 2 commits
+ git-status -v: color diff output when color.ui is set
+ git-commit: color status output when color.ui is set
* rs/maint-shortlog-foldline (Tue Jan 6 21:41:06 2009 +0100) 1 commit
+ shortlog: handle multi-line subjects like log --pretty=oneline et.
al. do
* rs/fgrep (Sat Jan 10 00:18:34 2009 +0100) 2 commits
+ grep: don't call regexec() for fixed strings
+ grep -w: forward to next possible position after rejected match
* as/autocorrect-alias (Sun Jan 4 18:16:01 2009 +0100) 1 commit
+ git.c: make autocorrected aliases work
* tr/maint-no-index-fixes (Wed Jan 7 12:15:30 2009 +0100) 3 commits
+ diff --no-index -q: fix endless loop
+ diff --no-index: test for pager after option parsing
+ diff: accept -- when using --no-index
* jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
+ format-patch: show patch text for the root commit
* ap/clone-into-empty (Sun Jan 11 15:19:12 2009 +0300) 2 commits
+ Allow cloning to an existing empty directory
+ add is_dot_or_dotdot inline function
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
+ gitweb: link to patch(es) view in commit(diff) and (short)log view
+ gitweb: add patches view
+ gitweb: change call pattern for git_commitdiff
+ gitweb: add patch view
----------------------------------------------------------------
[On Hold]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* What's in git.git (Jan 2009, #01; Wed, 14)
From: Junio C Hamano @ 2009-01-14 11:32 UTC (permalink / raw)
To: git
Many topics graduated to 'master' and I updated the draft release notes
for 1.6.2.
* The 'maint' branch has these fixes since the last announcement.
Clemens Buchacher (1):
modify/delete conflict resolution overwrites untracked file
Felipe Contreras (1):
fast-import: Cleanup mode setting.
Henrik Austad (2):
Use capitalized names where appropriate
Be consistent in switch usage for tar
Jay Soffian (1):
Git.pm: call Error::Simple() properly
Joey Hess (1):
README: tutorial.txt is now called gittutorial.txt
Johannes Schindelin (1):
merge-recursive: mark rename/delete conflict as unmerged
Junio C Hamano (3):
merge-recursive: do not clobber untracked working tree garbage
builtin-apply: prevent non-explicit permission changes
git checkout: do not allow switching to a tree-ish that is not a commit
Kirill A. Korinskiy (1):
http-push: support full URI in handle_remote_ls_ctx()
Markus Heidelberg (1):
doc/git-send-email: mention sendemail.cc config variable
Miklos Vajna (1):
fast-export: print usage when no options specified
Pierre Habouzit (1):
Avoid spurious error messages on error mistakes.
jidanni@jidanni.org (3):
Documentation/git-tag.txt: minor typo and grammar fix
Documentation/git-push.txt: minor: compress one option
contrib/examples/README: give an explanation of the status of these files
* The 'master' branch has these since the last announcement
in addition to the above.
Adeodato Simó (2):
builtin-shortlog.c: use string_list_append(), and don't strdup
unnecessarily
t7501-commit.sh: explicitly check that -F prevents invoking the editor
Alexander Potashev (1):
remove trailing LF in die() messages
Charles Bailey (4):
Fix some tab/space inconsistencies in git-mergetool.sh
Add -y/--no-prompt option to mergetool
mergetool: Add prompt to continue after failing to merge a file
mergetool: Don't keep temporary merge files unless told to
Christian Couder (1):
sha1_file: make "read_object" static
Clemens Buchacher (3):
unpack-trees: handle failure in verify_absent
unpack-trees: fix path search bug in verify_absent
unpack-trees: remove redundant path search in verify_absent
Eric Wong (1):
git-svn: add --authors-file test
Fabian Emmes (2):
cvsserver: add option to configure commit message
cvsserver: change generation of CVS author names
Giuseppe Bilotta (1):
gitweb: use href() when generating URLs in OPML
Jakub Narebski (3):
gitweb: Move 'lineno' id from link to row element in git_blame
gitweb: A bit of code cleanup in git_blame()
gitweb: cache $parent_commit info in git_blame()
Jeff King (1):
Makefile: clean up TEST_PROGRAMS definition
Johannes Schindelin (5):
git wrapper: Make while loop more reader-friendly
bisect view: call gitk if Cygwin's SESSIONNAME variable is set
bundle: allow rev-list options to exclude annotated tags
git add: do not add files from a submodule
show <tag>: reuse pp_user_info() instead of duplicating code
Jon Loeliger (1):
Fix Documentation typos surrounding the word 'handful'.
Junio C Hamano (2):
ls-tree: add --full-tree option
Update 1.6.2 draft release notes
Kjetil Barvik (1):
Cleanup of unused symcache variable inside diff-lib.c
Lee Marlow (2):
bash completion: Add '--intent-to-add' long option for 'git add'
bash completion: Use 'git add' completions for 'git stage'
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
Markus Heidelberg (3):
git-cherry: make <upstream> parameter optional
Documentation: clarify which parameters are optional to git-cherry
contrib/vim: change URL to point to the latest syntax files
Matt Kraai (1):
gitweb: unify boolean feature subroutines
Miklos Vajna (1):
Add support for a pdf version of the user manual
Nanako Shiraishi (1):
Document git-ls-tree --full-tree
Nguyễn Thái Ngọc Duy (2):
grep: support --no-ext-grep to test builtin grep
grep: grep cache entries if they are "assume unchanged"
Nicolas Pitre (1):
objects to be pruned immediately don't have to be loosened
Paul Jarc (1):
configure clobbers LDFLAGS
Philippe Bruhat (1):
Git.pm: correctly handle directory name that evaluates to "false"
Pierre Habouzit (1):
filter-branch: add git_commit_non_empty_tree and --prune-empty.
René Scharfe (2):
diff: add option to show context between close hunks
strbuf: instate cleanup rule in case of non-memory errors
SZEDER Gábor (1):
bash: add '--merge' to 'git reset'
William Pursell (2):
Add subroutine to display one-line summary of hunks
Add 'g' command to go to a hunk
^ permalink raw reply
* Re: [PATCH 1/3] git-daemon: single-line logs
From: Junio C Hamano @ 2009-01-14 11:33 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0901141147120.16109@fbirervta.pbzchgretzou.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
> parent v1.6.1
>
> git-daemon: single-line logs
Please drop these two needless lines when/if you are submitting patches
for inclusion..
> Having just a single line per connection attempt, much like Apache
> httpd2 access logs, makes log parsing much easier, especially when
> just glancing over it non-automated.
While I like the motivation, and I wish the log were as terse as possible
from the day one, I think changing the output format unconditionally like
this patch does is a horrible idea. I'd expect there are many people who
already have their infrastructure set up to parse the current output; this
patch actively breaks things for them, doesn't it?
> @@ -295,12 +295,13 @@ static int git_daemon_config(const char
> return 0;
> }
>
> -static int run_service(char *dir, struct daemon_service *service)
> +static int run_service(char *dir, struct daemon_service *service,
> + const char *origin, const char *vhost)
> {
> const char *path;
> int enabled = service->enabled;
>
> - loginfo("Request %s for '%s'", service->name, dir);
> + loginfo("%s->%s %s \"%s\"\n", origin, vhost, service->name, dir);
Mental note. You are adding origin and vhost probably because you are
losing them from elsewhere..
> @@ -507,10 +508,10 @@ static void parse_extra_args(char *extra
> static int execute(struct sockaddr *addr)
> {
> static char line[1000];
> + char addrbuf[256] = "";
> int pktlen, len, i;
>
> if (addr) {
> - char addrbuf[256] = "";
> int port = -1;
>
> if (addr->sa_family == AF_INET) {
> @@ -529,7 +530,6 @@ static int execute(struct sockaddr *addr
> port = ntohs(sin6_addr->sin6_port);
> #endif
> }
> - loginfo("Connection from %s:%d", addrbuf, port);
Mental note. Port is not logged anymore here.
> @@ -541,10 +541,6 @@ static int execute(struct sockaddr *addr
> alarm(0);
>
> len = strlen(line);
> - if (pktlen != len)
> - loginfo("Extended attributes (%d bytes) exist <%.*s>",
> - (int) pktlen - len,
> - (int) pktlen - len, line + len + 1);
Mental note. XA are not logged here anymore.
> @@ -569,7 +565,8 @@ static int execute(struct sockaddr *addr
> * Note: The directory here is probably context sensitive,
> * and might depend on the actual service being performed.
> */
> - return run_service(line + namelen + 5, s);
> + return run_service(line + namelen + 5, s,
> + addrbuf, hostname);
> }
> }
So not just you are changing the format, but you are losing information as
well.
By the way, I think hostname has already been freed and NULLed at this
call site. Aren't you getting entries like:
192.168.0.1->(null) upload-pack "/pub/git.git"
in your log?
^ permalink raw reply
* Re: [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname
From: Junio C Hamano @ 2009-01-14 11:33 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0901141148130.16109@fbirervta.pbzchgretzou.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
> parent v1.6.1
>
> git-daemon: use getnameinfo to resolve hostname
>
> This is much shorter than inet_ntop'ing, and also translated
> unresolvable addresses into a string.
translated? (I think you meant "translates" but my English is bad, so I
am double checking).
This indeed is much nicer, provided if it is available at least as widely
as inet_ntop() is.
We seem to ship inet_ntop() in compat/; a few questions.
(1) Do we need similar compat/ function for getnameinfo()? I am guessing
that most likely places are the ones that need NO_INET_NTOP and
NO_INET_PTON, and googling seems to indicate old Cygwin and HP-UX
11.00 may be among them.
(2) Do we still use inet_ntop() elsewhere, and if not, can we remove the
compat/ definitions?
^ permalink raw reply
* Re: [PATCH 3/3] git-daemon: vhost support
From: Junio C Hamano @ 2009-01-14 11:33 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0901141148390.16109@fbirervta.pbzchgretzou.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
> parent v1.6.1
>
> git-daemon: support vhosts
>
> Since git clients usually send the target hostname in the request
> similar to the "Host:" HTTP header, one can do virtual hosting.
Isn't this what --interpolated-path option (especially H and CH
interpolations) is about?
^ permalink raw reply
* Re: [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname
From: Jeff King @ 2009-01-14 12:25 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0901141148130.16109@fbirervta.pbzchgretzou.qr>
On Wed, Jan 14, 2009 at 11:48:38AM +0100, Jan Engelhardt wrote:
> This is much shorter than inet_ntop'ing, and also translated
> unresolvable addresses into a string.
Er, doesn't this totally change the meaning of REMOTE_ADDR from an IP
address to a hostname? That seems bad because:
- people already have hooks that compare REMOTE_ADDR against an
address, so we are breaking their hooks
- we are losing IP information in favor of hostname information; since
(I assume) this is primarily intended for IP-based access control,
we are adding an extra layer of indirection in the middle of our
security model (i.e., I used to have to spoof an IP to fool your
hook, but now I can do that _or_ spoof DNS).
So at the very least, you should be adding REMOTE_HOST in _addition_ to
REMOTE_ADDR, not instead of. But that still leaves one final concern,
which is that some git-daemon admins might not want to pay the cost for
a reverse lookup for every request. It's extra network traffic, and adds
extra latency to the process (but I don't personally run git-daemon, and
I don't know whether big sites like kernel.org actually care about
this).
-Peff
^ permalink raw reply
* Re: [PATCH 0/4] refactor the --color-words to make it more hackable
From: Santi Béjar @ 2009-01-14 13:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901112057300.3586@pacific.mpi-cbg.de>
2009/1/11 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
[...]
> The basic idea is to decouple the original text from the text that is
> passed to libxdiff to find the word differences.
>
> To that end, the words of the pre and post texts are put into two lists that
> are fed to libxdiff. While the words are extracted, an array is created which
> contains pointers back to the word boundaries in the original text.
>
Thanks. With this I will no longer need to add some spurious spaces in
my latex files :-)
I've tested and it seems to work, but there are some corner cases that
it does not handle well. If you have this two files:
---8<--- pre
h(4)
a = b + c
---8<--- post
h(4),hh[44]
a = b + c
aa = a
aeff = aeff * ( aaa )
---8<---
The "git diff" is okay, but not the "git diff --color-words", the
addition of "aeff = ..." is not shown.
Additionally with "git diff --no-index --color-words='^[A-Za-z0-9]*'
the ']' character is not shown as an addition, and instead of the
"aeff" line you get a ")" in green, as:
h(4),{GREEN}hh[44{ENDGREEN}]
a = b + c
{GREEN}aa = a
){ENDGREEN}
Also if the lost text is at the end the next "diff --git" line is
printed in read:
--8<---
#!/bin/bash
git init
cat > file <<EOF
a
aa
EOF
cat > gfile <<EOF
a
EOF
git add .
git commit -m "Initial import"
git rm file
cat > gfile <<EOF
b
EOF
git add gfile
git commit -m "changes"
git show --color-words
---8<---
Thanks,
Santi
P.D.: I've test the version that is in 'pu', it does not have the
patch to fix the segfault but I've also tested with it.
^ permalink raw reply
* Re: [PATCH 1/3] git-daemon: single-line logs
From: Jan Engelhardt @ 2009-01-14 13:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6xe2kbx.fsf@gitster.siamese.dyndns.org>
On Wednesday 2009-01-14 12:33, Junio C Hamano wrote:
>
>> parent v1.6.1
>>
>> git-daemon: single-line logs
>
>Please drop these two needless lines when/if you are submitting patches
>for inclusion..
The patches are produced by my git-export-patch script (or in this
specific case it was quilt); so they usually look like this.
Especially when I do make mental notes that do not go into the
commit log, the patch is tacked on, as in, for example,
http://marc.info/?l=netfilter-devel&m=123191159015731&w=2
>> Having just a single line per connection attempt, much like Apache
>> httpd2 access logs, makes log parsing much easier, especially when
>> just glancing over it non-automated.
>
>While I like the motivation, and I wish the log were as terse as possible
>from the day one,
Well, why did no one do it like that then? My guess is that it was not a
"real" logging infrastructure but more of a debug aid. Especially when
it required --syslog --verbose to pass to git-daemon this seems like
--debug=yesPlease.
>I think changing the output format unconditionally like
>this patch does is a horrible idea. I'd expect there are many people who
>already have their infrastructure set up to parse the current output; this
>patch actively breaks things for them, doesn't it?
Probably. Which just shows that git-daemon is in need of
some configuration .. thing so that each user can choose
his own if desired.
>> @@ -295,12 +295,13 @@ static int git_daemon_config(const char
>> -static int run_service(char *dir, struct daemon_service *service)
>> +static int run_service(char *dir, struct daemon_service *service,
>> + const char *origin, const char *vhost)
>> {
>> const char *path;
>> int enabled = service->enabled;
>>
>> - loginfo("Request %s for '%s'", service->name, dir);
>> + loginfo("%s->%s %s \"%s\"\n", origin, vhost, service->name, dir);
>
>Mental note. You are adding origin and vhost probably because you are
>losing them from elsewhere..
Not quite sure what you mean by losing.
But in 1.6.0.x, run_service had a variable interp of type itable or so
and it was possible to use interp[SLOT_DIR].val without someone raising
a hand declaring I lost them elsewhere ;-)
>> @@ -529,7 +530,6 @@ static int execute(struct sockaddr *addr
>> port = ntohs(sin6_addr->sin6_port);
>> #endif
>> }
>> - loginfo("Connection from %s:%d", addrbuf, port);
>
>Mental note. Port is not logged anymore here.
Right, I did not see a need for it, and it in itself just stood
in the way of getting 1-line-output.
>> @@ -541,10 +541,6 @@ static int execute(struct sockaddr *addr
>> alarm(0);
>>
>> len = strlen(line);
>> - if (pktlen != len)
>> - loginfo("Extended attributes (%d bytes) exist <%.*s>",
>> - (int) pktlen - len,
>> - (int) pktlen - len, line + len + 1);
>
>Mental note. XA are not logged here anymore.
I only ever saw the hostname XA, and this is still logged.
>> @@ -569,7 +565,8 @@ static int execute(struct sockaddr *addr
>> * Note: The directory here is probably context sensitive,
>> * and might depend on the actual service being performed.
>> */
>> - return run_service(line + namelen + 5, s);
>> + return run_service(line + namelen + 5, s,
>> + addrbuf, hostname);
>> }
>> }
>
>So not just you are changing the format, but you are losing information as
>well.
>
>By the way, I think hostname has already been freed and NULLed at this
>call site. Aren't you getting entries like:
>
> 192.168.0.1->(null) upload-pack "/pub/git.git"
>
>in your log?
No. Which means someone succeeded at obfuscating daemon.c.
It seems that parse_extra_args() sets hostname again after it has been
NULLified just moments ago.
^ permalink raw reply
* Re: [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname
From: Jan Engelhardt @ 2009-01-14 13:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsknm2kbs.fsf@gitster.siamese.dyndns.org>
On Wednesday 2009-01-14 12:33, Junio C Hamano wrote:
>> git-daemon: use getnameinfo to resolve hostname
>>
>> This is much shorter than inet_ntop'ing, and also translated
>> unresolvable addresses into a string.
>
>translated? (I think you meant "translates" but my English is bad, so I
>am double checking).
yes, keyboard slipped away.
>This indeed is much nicer, provided if it is available at least as widely
>as inet_ntop() is.
Both inet_ntop and getnameinfo are in POSIX.1-2001.
> (1) Do we need similar compat/ function for getnameinfo()? I am guessing
> that most likely places are the ones that need NO_INET_NTOP and
> NO_INET_PTON, and googling seems to indicate old Cygwin and HP-UX
> 11.00 may be among them.
>
> (2) Do we still use inet_ntop() elsewhere, and if not, can we remove the
> compat/ definitions?
>
Yes, it is still used elsewhere.
^ permalink raw reply
* Re: [PATCH 3/3] git-daemon: vhost support
From: Jan Engelhardt @ 2009-01-14 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmydu2kbj.fsf@gitster.siamese.dyndns.org>
On Wednesday 2009-01-14 12:33, Junio C Hamano wrote:
>> git-daemon: support vhosts
>>
>> Since git clients usually send the target hostname in the request
>> similar to the "Host:" HTTP header, one can do virtual hosting.
>
>Isn't this what --interpolated-path option (especially H and CH
>interpolations) is about?
Looks like it. In this case this third patch is not needed.
^ permalink raw reply
* [BUG] assertion failure in builtin-mv.c with "git mv -k"
From: Matthieu Moy @ 2009-01-14 13:20 UTC (permalink / raw)
To: git
Hi,
Just found a bug in builtin-mv.c. Here's a script to reproduce:
mkdir git
cd git
git init
touch controled
git add controled && git commit -m "init"
touch foo1 foo2
mkdir dir
git mv -k foo* dir/
The output is the following:
Initialized empty Git repository in /tmp/git/.git/
[master (root-commit)]: created 694563b: "init"
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 controled
git: builtin-mv.c:216: cmd_mv: Assertion `pos >= 0' failed.
./bug.sh: line 10: 12919 Aborted git mv -k foo* dir/
Apparently, this happens when using "git mv -k" with more than one
unversionned file. The code ignores the first one, but still goes
through this
for (i = 0; i < argc; i++) {
const char *src = source[i], *dst = destination[i];
enum update_mode mode = modes[i];
int pos;
if (show_only || verbose)
printf("Renaming %s to %s\n", src, dst);
if (!show_only && mode != INDEX &&
rename(src, dst) < 0 && !ignore_errors)
die ("renaming %s failed: %s", src, strerror(errno));
if (mode == WORKING_DIRECTORY)
continue;
pos = cache_name_pos(src, strlen(src));
assert(pos >= 0); /* <----- this is the one */
if (!show_only)
rename_cache_entry_at(pos, dst);
}
for the second, and it crashes on the assertion (gdb says "pos" here
is an unversionned file name).
If anyone has time to fix this ...
Thanks,
--
Matthieu
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Alex Riesen @ 2009-01-14 13:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: skillzero, git
In-Reply-To: <200901140941.17110.trast@student.ethz.ch>
2009/1/14 Thomas Rast <trast@student.ethz.ch>:
> skillzero@gmail.com wrote:
>> That's what I was somewhat disappointed by. Even though the result of
>> the commit had a different hash, I assumed git would keep some kind of
>> internal per-commit hash so it could tell later that two commits were
>> the same and not re-apply them.
>
> I think there's an important misunderstanding here: merging A into B
> does *not* have anything to do with commits, or history for that
> matter, beyond the differences from $(git merge-base A B) to A and
> B.[*]
>
> Along the same lines, nothing is ever re-applied during merging.
> git-merge just figures out that you made the same change on both
> sides, so it must have been a good change, so it must go into the end
> result. *How* you arrived at the same change---say, by
> cherry-picking, or by getting the same result in that region from
> otherwise different commits, or even from several commits---does *not*
> matter in any way.
Yes, merge only considers what bytes (aka contents of
trees-directories and blobs-files) do the branches to be merged
have, compares them (by comparing their hashes) and if there
are differences tries to mix them together according to the merge
rules described somewhere in Documentation.
So this all is really just about what the branches contain, not
how they got it. It is the conflict resolution algorithm which uses
the history to find the best possible source blob or tree which was
changed by conflicting branches so the "mix" can be prepared as
close as possible to what would we do if we went looking for the
pieces manually.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Fix nested links problem with ref markers
From: Giuseppe Bilotta @ 2009-01-14 13:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901141139.42263.jnareb@gmail.com>
On Wed, Jan 14, 2009 at 5:39 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 14 Jan 2009, Giuseppe Bilotta wrote:
>> On Tue, Jan 13, 2009 at 7:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Tue, 13 Jan 2009, Giuseppe Bilotta wrote:
>
>>>> Can you provide a patch I can apply to my tree for testing to see how
>>>> it comes up?
>>>
>>> Here it is. Note that CSS could be I think reduced. The size of
>>> gitweb.perl changes is affected by changing calling convention for
>>> git_print_header_html subroutine.
>>
>> It's funny, I was working on a very similar patch myself a couple of
>> days ago, but couldn't get the horizontal filler after the link to
>> work properly, which is why I asked on www-style.
>>
>> I'll test your patch and let you know.
>
> I am checking 'log' view of git repository; it should have enough
> ref markers to test this issue.
>
> It works also in Konqueror 3.5.3-0.2.fc4...
>
>>> There is also strange artifact at least in Mozilla 1.17.2: if I hover
>>> over ref marker, the subject (title) gets darker background. Curious...
>>
>> Might be some kind of bug with the capturing vs bubbling phase.
>
> ...but the same artifact can be seen too. Also I am not entirely
> pleased with the way things behave on mouseover. It is a pity that
> you cannot style element using CSS2.1 based on the pseudo-class :hover
> of descendant element, or/and pseudo-class of sibling element, which
> nevertheless overlays given element.
I know, I've been needing something like this in other occasion. And
that's precisely what I was talking about for the limits of CSS, and
why I really wonder if the illegal XHMTL but valid XML shouldn't
rather be our option ...
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes? (a solution)
From: Jakub Narebski @ 2009-01-14 13:55 UTC (permalink / raw)
To: Mike Hommey
Cc: Alex Riesen, git, Markus Heidelberg, Asheesh Laroia,
Luciano Rocha, J.H.
In-Reply-To: <200901130043.04772.jnareb@gmail.com>
Jakub Narebski wrote:
> The ISP I use (Telekomunikacja Polska S.A., aka TP) made some
> unannounced changes for ADSL service (Neostrada) which made it block
> repo.or.cz (and of course its aliases, including git.or.cz where git
> wiki resides).
Thank you all for your help with arriving at solution. I'll describe it
below; perhaps it would help somebody else (now that it is in mailing
list archive).
First, let me explain what I am working with:
I have access to shell account with set up SSH key access; let's name
this machine host.example.com. I don't have admin rights there, and
quota is quite tight; I have installed netcat (nc) in ~/bin - it is
only 22 kB.
I don't know where to find SOCKS5 proxy, and I don't have 'tsocks'
installed either on my computer, or on shell account... I think.
Now, solutions:
1. For reading gitweb at repo.or.cz, and for reading and editing git
wiki at http://git.or.cz/gitwiki/ I use one of free HTTP proxies:
http://www.4proxy.de (first such proxy I have found that has an
option to _not_ obfuscate URLs; it still unnecessary escapes some
things like '/' in the query argument).
2. For pushing changes to repo.or.cz I use SSH tunnel (I could have
used ProxyCommand solution with netcat instead[1]). I run:
$ autossh -M 2000 -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
at startup, and I have set the following in ~/.ssh/config:
# TP S.A. blocks repo.or.cz
Host repo.or.cz
#ssh -f -N -L 2222:repo.or.cz:22 host.example.com
NoHostAuthenticationForLocalhost yes
HostName localhost
Port 2222
[1] Alternate solution:
# TP S.A. blocks repo.or.cz
Host repo.or.cz
ProxyCommand ssh host.example.com exec /home/jnareb/bin/nc %h %p
3. For fetching changes via git:// protocol from repo.or.cz I use the
following setup in git config:
[core]
gitProxy = ssh-proxy for "repo.or.cz"
Unfortunately example from Documentation/config.txt with "ssh" as
git proxy command doesn't work, and neither putting command with
options (e.g. "ssh host.example.com /home/jnareb/bin/nc") doesn't
work: the command is _not_ split on whitespace. So I had to use
helper script ~/bin/ssh-proxy:
#!/bin/sh
ssh host.example.com /home/jnareb/bin/nc "$1" "$2"
I hope that would help somebody... and if somebody notices better
solution, hs/she would provide me with it :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname
From: Adeodato Simó @ 2009-01-14 14:17 UTC (permalink / raw)
To: Jeff King; +Cc: Jan Engelhardt, git
In-Reply-To: <20090114122536.GA5939@coredump.intra.peff.net>
* Jeff King [Wed, 14 Jan 2009 07:25:36 -0500]:
> On Wed, Jan 14, 2009 at 11:48:38AM +0100, Jan Engelhardt wrote:
> > This is much shorter than inet_ntop'ing, and also translated
> > unresolvable addresses into a string.
> Er, doesn't this totally change the meaning of REMOTE_ADDR from an IP
> address to a hostname?
Yes, I believe so.
However, AFAIK you can obtain the intended behavior if you pass
NI_NUMERICHOST as a flag to the getnameinfo() call. With that, this
patch can be still considered for inclusing if the original "don't
hardcode protocol-specific bits" is still deemed worthy.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
- Why are you whispering?
- Because I just think that no matter where she is, my mom can hear this
conversation.
-- Rory and Lane
^ 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