* [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
From: Luben Tuikov @ 2006-07-13 3:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Teach tree->raw to not require the hash of the blob, but to
figure it out from the file name. This allows to externally
link to files into the repository, such that the hash is not
required. I.e. the file obtained would be as of the HEAD
commit.
In contrast tree->blob for binary files passes the hash, as
does tree->blob->plain for "text/*" files.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.cgi | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
[-- Attachment #2: pat867582916 --]
[-- Type: application/octet-stream, Size: 2055 bytes --]
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 2e87de4..e904eb7 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -1521,6 +1521,14 @@ sub git_blob_plain_mimetype {
}
sub git_blob_plain {
+ if (!defined $hash) {
+ if (defined $file_name) {
+ my $base = $hash_base || git_read_head($project);
+ $hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
+ } else {
+ die_error(undef, "No file name defined.");
+ }
+ }
my $type = shift;
open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error("Couldn't cat $file_name, $hash");
@@ -1544,9 +1552,13 @@ sub git_blob_plain {
}
sub git_blob {
- if (!defined $hash && defined $file_name) {
- my $base = $hash_base || git_read_head($project);
- $hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
+ if (!defined $hash) {
+ if (defined $file_name) {
+ my $base = $hash_base || git_read_head($project);
+ $hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
+ } else {
+ die_error(undef, "No file name defined.");
+ }
}
my $have_blame = git_get_project_config_bool ('blame');
open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
@@ -1678,8 +1690,7 @@ sub git_tree {
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$t_hash$base_key;f=$base$t_name")}, "blob") .
# " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blame;h=$t_hash$base_key;f=$base$t_name")}, "blame") .
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=history;h=$hash_base;f=$base$t_name")}, "history") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$t_hash;f=$base$t_name")}, "raw") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;f=$base$t_name")}, "raw") .
"</td>\n";
} elsif ($t_type eq "tree") {
print "<td class=\"list\">" .
--
1.4.1.g9ca3
^ permalink raw reply related
* Re: Error writing loose object on Cygwin
From: Junio C Hamano @ 2006-07-13 4:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060712050016.GA8002@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Tomorrow when I get access to my Cygwin system again I'll try to
> write up a tiny test case which shows the error behavior we are
> seeing and send it to the Cygwin mailing list, as this really does
> seem to be a Cygwin or Windows issue. But of course having GIT
> handle this case slightly better wouldn't be bad either. :-)
Surely, and thanks. I'll await for a follow-up report, and
until then will hold onto this patch.
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Junio C Hamano @ 2006-07-13 4:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607120931150.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So being somewhat forgiving might help, but I think another thing that
> migth help is a flag to "git-am" to _not_ apply a patch that lacks a
> previous sign-off.
How about having this in $GIT_DIR/hooks/applypatch-msg?
#!/bin/sh
grep '^Signed-off-by: ' "$1" >/dev/null
^ permalink raw reply
* git-fmt-merge-message problem..
From: Linus Torvalds @ 2006-07-13 4:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
Not a huge one, but it's ugly.
When I did a "git pull repo", the merge messages _used_ to look like this:
Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[NEIGH]: Fix IP-over-ATM and ARP interaction.
[TG3]: ethtool always report port is TP.
or (if I specified a branch):
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ro
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infini
IB/mthca: FMR ioremap fix
IPoIB: Free child interfaces properly
IB/mthca: Fix race in reference counting
IB/srp: Fix tracking of pending requests during error handling
IB: Fix display of 4-bit port counters in sysfs
but now they look like this:
Merge commit master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 of HEAD
* HEAD:
[NET]: fix __sk_stream_mem_reclaim
[Bluetooth] Fix deadlock in the L2CAP layer
[Bluetooth] Let BT_HIDP depend on INPUT
[Bluetooth] Avoid NULL pointer dereference with tty->driver
[Bluetooth] Remaining transitions to use kzalloc()
[WAN]: converting generic HDLC to use netif_dormant*()
[IPV4]: Fix error handling for fib_insert_node call
[NETROM] lockdep: fix false positive
....
which makes no sense AT ALL. It's doesn't even parse. "Merge commit <repo>
of <branch>"? Whaa? That's just insane.
Also, the " * HEAD" is just ugly. It was better before.
Dscho? Can you please make git fmt-merge-message print out something
sensible again? It doesn't have to match the old behaviour 100%, but the
current one is just ugly and senseless.
Linus
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Junio C Hamano @ 2006-07-13 4:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0607120415g243f2160tf42c40e52b8bc9ac@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> It is really annoying when the essentials do not work.
> I think we could improve at least them, by minimizing
> their dependencies to external tools.
>
> ---
>
> git-commit.sh has only ohne place where perl is used
> and it can actually quite trivially be done in sh.
> git-ls-files without "-z" produces quoted output, even if
> is different from that produced by perl code it could be
> enough. Otherwise I'd better suggest to add another
> quoting style (replacing only \t, \n and backslash) than
> having to constantly patch git-commit.sh for binmode
> or perl path (Windows has no stable tool set, and perl
> for instance often resides "somewhere").
(1) Sign-off?
(2) I think the cover letter comment talks more apporpirate
things than your proposed commit message. The commit log is
not a place to vent your frustration. It's where you
justify why that change was needed for people who will want
to figure out why your patch broke their workflow later.
I do not think anybody parses git-status output to figure out
the list of paths that are touched/untracked/etc., so I am not
opposed to this change itself.
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Linus Torvalds @ 2006-07-13 4:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac7exgvs.fsf@assigned-by-dhcp.cox.net>
On Wed, 12 Jul 2006, Junio C Hamano wrote:
>
> How about having this in $GIT_DIR/hooks/applypatch-msg?
>
> #!/bin/sh
> grep '^Signed-off-by: ' "$1" >/dev/null
Not good, because then I have no way to select a different behaviour with
a flag. If I decide it was ok to apply (say, it's just a silly typo fix),
I would want to say so.
Linus
^ permalink raw reply
* Re: [PATCH] documentation about exclude/ignore files
From: Junio C Hamano @ 2006-07-13 4:40 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G0knL-0007PL-86@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> ---
> Use .git/info/exclude in the example in git-ls-files.txt as .gitignore
> is used there and update the list of commands looking at
> .git/info/exclude in repository-layout.txt.
>
> ---
> Documentation/git-ls-files.txt | 4 ++--
> Documentation/repository-layout.txt | 8 +++++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
Why do you start the message with three dashes that says "the
below will _not_ go to the commit log message"?
The changes look good. Please sign your patches.
^ permalink raw reply
* Re: [PATCH] Documentation: Fix ssh:// URLs in generated documentation
From: Junio C Hamano @ 2006-07-13 4:58 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <11527413212127-git-send-email-alp@atoker.com>
Alp Toker <alp@atoker.com> writes:
> Commit c3f17061be95de3498449a548e93883aebff23d6 was causing warnings
> during doc generation due to bad asciidoc markup.
>
> This resulted in "ssh://[user@]host.xz/path/to/repo.git/" being rendered
> as "host.xz/path/to/repo.git/" in the man pages and html output.
I wonder if this is with less formatting impact then.
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 9abec80..93378d2 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -10,9 +10,9 @@ to name the remote repository:
- https://host.xz/path/to/repo.git/
- git://host.xz/path/to/repo.git/
- git://host.xz/~user/path/to/repo.git/
-- ssh://[user@]host.xz/path/to/repo.git/
-- ssh://[user@]host.xz/~user/path/to/repo.git/
-- ssh://[user@]host.xz/~/path/to/repo.git
+- ssh://+++[user@+++]host.xz/path/to/repo.git/
+- ssh://+++[user@+++]host.xz/~user/path/to/repo.git/
+- ssh://+++[user@+++]host.xz/~/path/to/repo.git
===============================================================
SSH Is the default transport protocol and also supports an
^ permalink raw reply related
* Re: git-fmt-merge-message problem..
From: Junio C Hamano @ 2006-07-13 5:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0607122133250.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> which makes no sense AT ALL. It's doesn't even parse. "Merge commit <repo>
> of <branch>"? Whaa? That's just insane.
>
> Also, the " * HEAD" is just ugly. It was better before.
Yes, this is a simple mistranslation from Perl to C. A patch
will follow shortly.
^ permalink raw reply
* Re: git-fmt-merge-message problem..
From: Junio C Hamano @ 2006-07-13 5:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Johannes Schindelin
In-Reply-To: <7vlkqyw0om.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> which makes no sense AT ALL. It's doesn't even parse. "Merge commit <repo>
>> of <branch>"? Whaa? That's just insane.
>>
>> Also, the " * HEAD" is just ugly. It was better before.
>
> Yes, this is a simple mistranslation from Perl to C. A patch
> will follow shortly.
-- >8 --
[PATCH] fmt-merge-msg fix
The new C version mistranslated the original Perl version in the
case to pull from the HEAD. This made it to say nonsense like
this:
Merge commit ...url... of HEAD
* HEAD:
...
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-fmt-merge-msg.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 6527482..fe0ef44 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -76,6 +76,7 @@ static int handle_line(char *line)
unsigned char *sha1;
char *src, *origin;
struct src_data *src_data;
+ int pulling_head = 0;
if (len < 43 || line[40] != '\t')
return 1;
@@ -101,8 +102,11 @@ static int handle_line(char *line)
if (src) {
*src = 0;
src += 4;
- } else
- src = "HEAD";
+ pulling_head = 0;
+ } else {
+ src = line;
+ pulling_head = 1;
+ }
i = find_in_list(&srcs, src);
if (i < 0) {
@@ -112,7 +116,10 @@ static int handle_line(char *line)
}
src_data = srcs.payload[i];
- if (!strncmp(line, "branch ", 7)) {
+ if (pulling_head) {
+ origin = strdup(src);
+ src_data->head_status |= 1;
+ } else if (!strncmp(line, "branch ", 7)) {
origin = strdup(line + 7);
append_to_list(&src_data->branch, origin, NULL);
src_data->head_status |= 2;
@@ -124,9 +131,6 @@ static int handle_line(char *line)
origin = strdup(line + 14);
append_to_list(&src_data->r_branch, origin, NULL);
src_data->head_status |= 2;
- } else if (!strcmp(line, "HEAD")) {
- origin = strdup(src);
- src_data->head_status |= 1;
} else {
origin = strdup(src);
append_to_list(&src_data->generic, strdup(line), NULL);
^ permalink raw reply related
* Re: git-fmt-merge-message problem..
From: Linus Torvalds @ 2006-07-13 5:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vlkqyw0om.fsf@assigned-by-dhcp.cox.net>
On Wed, 12 Jul 2006, Junio C Hamano wrote:
>
> Yes, this is a simple mistranslation from Perl to C. A patch
> will follow shortly.
On a similar vein, how about this?
I always end up editing the revert sentence by hand to make grammatical
sense.
I think we always talk about "commit xyz".
We never talk about "xyz commit", except when we end up talking about a
commit as a branch head (notably, I would say "the HEAD commit", or
possibly "the top-of-master commit", but here $commit is a SHA1 name, not
anything else).
Hmm?
Linus
---
diff --git a/git-revert.sh b/git-revert.sh
index de8b5f0..2bf35d1 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -84,7 +84,7 @@ revert)
s/^[^ ]* /Revert "/
s/$/"/'
echo
- echo "This reverts $commit commit."
+ echo "This reverts commit $commit."
test "$rev" = "$commit" ||
echo "(original 'git revert' arguments: $@)"
base=$commit next=$prev
^ permalink raw reply related
* Re: git-daemon problem
From: Junio C Hamano @ 2006-07-13 5:44 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G0kNV-0006LK-QW@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> This breaks the newer clients that knows how to do side-band
>> doesn't it?
> Probably, this patch is just to give a starting point where the
> problem could be.
>
>> Would this replacement patch help?
> [use write instead of safe_write]
>
> This seems to fix it. Perhaps it should be xwrite instead of write.
>
>> Maybe we should check if fd 2 is sane at daemon startup, and
>> otherwise open /dev/null for writing and dup2 it to fd 2?
> daemon startup is probably not the right place because as long as the
> terminal is open this will be fine.
Hmph. In the part of my message you did not quote:
$ git-daemon 0<&- 1>&- 2>&- --export-all /pub/git
leaves listening sockets at fd 0/1 without any fd 2, and
$ git-daemon 2>&- --export-all /pub/git
allocates listening socket at FD 2 (because FD 0 and FD 1 are
occupied).
Now, after we do accept(), we spawn a subprocess in handle(),
and in the child process dup2() the fd connected to the peer to
fd 0 and 1 of the child process -- and we do not do anything to
fd 2 of the child process. So in the latter case, my tentative
patch would write error message to the listening socket -- ugh.
And as you say, fd 2 might be connected to the terminal and
healthy when you start the daemon, but later you can close the
terminal, so there is no sane place for us to try anything
sensible.
The only "right" solution I could think of is to properly
daemonize git-daemon when not running under --inetd mode. Close
and open /dev/null the low three fds, and dissociate the process
from the controlling terminal (did I forget anything else --
perhaps chdir("/") at the top?). And we keep the current
behaviour of assuming the sane set of low three fds when a new
option --debug is given to help people look at its stderr. The
tentative patch to upload-pack would become moot at that point.
Hmm?
^ permalink raw reply
* Re: git-fmt-merge-message problem..
From: Junio C Hamano @ 2006-07-13 5:46 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0607122222310.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 12 Jul 2006, Junio C Hamano wrote:
>>
>> Yes, this is a simple mistranslation from Perl to C. A patch
>> will follow shortly.
>
> On a similar vein, how about this?
>
> I always end up editing the revert sentence by hand to make grammatical
> sense.
>
> I think we always talk about "commit xyz".
>
> We never talk about "xyz commit", except when we end up talking about a
> commit as a branch head (notably, I would say "the HEAD commit", or
> possibly "the top-of-master commit", but here $commit is a SHA1 name, not
> anything else).
>
> Hmm?
Makes sense. Sign-off ;-)?
I wonder if we would want to abbreviate this, though.
^ permalink raw reply
* Re: [PATCH] Documentation: Fix ssh:// URLs in generated documentation
From: Alp Toker @ 2006-07-13 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsgaw16d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I wonder if this is with less formatting impact then.
>
> diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> index 9abec80..93378d2 100644
> --- a/Documentation/urls.txt
> +++ b/Documentation/urls.txt
> @@ -10,9 +10,9 @@ to name the remote repository:
> - https://host.xz/path/to/repo.git/
> - git://host.xz/path/to/repo.git/
> - git://host.xz/~user/path/to/repo.git/
> -- ssh://[user@]host.xz/path/to/repo.git/
> -- ssh://[user@]host.xz/~user/path/to/repo.git/
> -- ssh://[user@]host.xz/~/path/to/repo.git
> +- ssh://+++[user@+++]host.xz/path/to/repo.git/
> +- ssh://+++[user@+++]host.xz/~user/path/to/repo.git/
> +- ssh://+++[user@+++]host.xz/~/path/to/repo.git
> ===============================================================
>
> SSH Is the default transport protocol and also supports an
Your call. I almost went that way but decided the more invasive patch
left the source a bit more readable as it didn't need escaping. As long
as the output gets fixed, nobody will be losing sleep over this one.
^ permalink raw reply
* Re: Error writing loose object on Cygwin
From: Christopher Faylor @ 2006-07-13 5:51 UTC (permalink / raw)
To: Junio C Hamano, Shawn Pearce, git
In-Reply-To: <7vr70r1ms5.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:
>Shawn Pearce <spearce@spearce.org> writes:
>
>> Has anyone else seen this type of behavior before? Any suggestions
>> on debugging this issue?
>
>I would suggest raising this (politely) to Cygwin people.
I lost the thread here but wasn't this referring to a samba mount? If so,
it would be samba that's returning the wrong "errno".
cgf
^ permalink raw reply
* Re: git-daemon problem
From: Matthias Lederhofer @ 2006-07-13 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveq2ukho.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
> > Junio C Hamano <junkio@cox.net> wrote:
> >> Maybe we should check if fd 2 is sane at daemon startup, and
> >> otherwise open /dev/null for writing and dup2 it to fd 2?
> > daemon startup is probably not the right place because as long as the
> > terminal is open this will be fine.
>
> Hmph. In the part of my message you did not quote:
>
> $ git-daemon 0<&- 1>&- 2>&- --export-all /pub/git
>
> leaves listening sockets at fd 0/1 without any fd 2, and
>
> $ git-daemon 2>&- --export-all /pub/git
>
> allocates listening socket at FD 2 (because FD 0 and FD 1 are
> occupied).
>
> Now, after we do accept(), we spawn a subprocess in handle(),
> and in the child process dup2() the fd connected to the peer to
> fd 0 and 1 of the child process -- and we do not do anything to
> fd 2 of the child process. So in the latter case, my tentative
> patch would write error message to the listening socket -- ugh.
>
> And as you say, fd 2 might be connected to the terminal and
> healthy when you start the daemon, but later you can close the
> terminal, so there is no sane place for us to try anything
> sensible.
>
> The only "right" solution I could think of is to properly
> daemonize git-daemon when not running under --inetd mode. Close
> and open /dev/null the low three fds, and dissociate the process
> from the controlling terminal (did I forget anything else --
> perhaps chdir("/") at the top?). And we keep the current
> behaviour of assuming the sane set of low three fds when a new
> option --debug is given to help people look at its stderr. The
> tentative patch to upload-pack would become moot at that point.
>
> Hmm?
Now I see what you mean. Checking the fds at daemon startup should
work too (using xwrite/write instead of safe_write).
Is daemon(3) portable? Otherwise it should be:
fork(); setsid(); chdir("/"); open("/dev/null", O_RDWR, 0); dup2(..);
(looking at the daemon(3) implementations of glibc and freebsd libc)
The freebsd implementation of daemon(3) ignores SIGHUP for fork() and
setsid() with the comment "A SIGHUP may be thrown when the parent
exits below."
With the option to run in background (or the other way around -- not
to run in background) should also come an option to write a pid file.
^ permalink raw reply
* Re: [PATCH] documentation about exclude/ignore files
From: Matthias Lederhofer @ 2006-07-13 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7uyw206.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Why do you start the message with three dashes that says "the
> below will _not_ go to the commit log message"?
I was not sure if this comment should really go into the commit
message.
> The changes look good. Please sign your patches.
Argh, I just keep forgetting this, sorry.
^ permalink raw reply
* Re: [PATCH] gitweb.css: Courer fonts for commits and tree-diff
From: Matthias Lederhofer @ 2006-07-13 7:57 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20060712174610.71046.qmail@web31810.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
> > But if I really have to, I would say this makes things uglier
> > and less readable. Maybe asking for monospace is less yucky but
> > naming Courier explicitly?
>
> Sometimes people would put ASCII art in their commit messages,
> things like a simple table, compiler output, log output, etc,
> and I wanted to _preserve_ the intent of such output. This is why
> I changed it to Courier. (sorry for the misspelling of Courier)
monospace should do this too, see[1]. I think it should be added as
fallback[2] at least but I see no reason not to use font-family:
monospace.
[1] http://www.w3.org/TR/REC-CSS2/fonts.html#monospace-def
[2] http://www.w3.org/TR/REC-CSS2/fonts.html#generic-font-families
^ permalink raw reply
* Re: git-fmt-merge-message problem..
From: Johannes Schindelin @ 2006-07-13 8:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607122133250.5623@g5.osdl.org>
Hi,
On Wed, 12 Jul 2006, Linus Torvalds wrote:
> Dscho? Can you please make git fmt-merge-message print out something
> sensible again?
Sorry for the breakage. I saw Junio already patched and pushed.
Ciao,
Dscho
^ permalink raw reply
* remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-13 8:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bd6xgnz.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]
git-commit.sh has the only one place where perl is used
and there it can quite trivially be done in sh.
git-ls-files without "-z" produces quoted output, even if
is different from that produced by perl code it could be
enough. Otherwise I'd better suggest to add another
quoting style (replacing only \t, \n and backslash).
This system is an ugly combination of cygwin and
activestate perl. The combination has some quirks
(like the perl producing \r\n by default, expecting
windows pathnames instead of cygwin fakes, or
ignoring environment variables under some hard to
reproduce circumstances), so reducing number of
this interactions reduces number of hacks one has
to put in core code to make things work. I used to
patch git-commit.sh to put binmode in perl output,
and git-clone.sh still has these calls to cygpath.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
It is really annoying when the essentials do not work.
I think we could improve at least them, by minimizing
their dependencies to external tools.
Junio C Hamano wrote:
> (1) Sign-off?
done
> (2) I think the cover letter comment talks more apporpirate
> things than your proposed commit message. The commit log is
> not a place to vent your frustration. It's where you
> justify why that change was needed for people who will want
> to figure out why your patch broke their workflow later.
done.
[-- Attachment #2: 0001-remove-perl-from-git-commit.sh.txt --]
[-- Type: text/plain, Size: 1501 bytes --]
From 69bf41df4ef69d0f1e4ab52942c59bb3fd568cb8 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 12 Jul 2006 13:02:23 +0200
Subject: remove perl from git-commit.sh
---
git-commit.sh | 32 +++++++++++++-------------------
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 802dd72..4cf3fab 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -138,32 +138,26 @@ #'
if test -z "$untracked_files"; then
option="--directory --no-empty-directory"
fi
+ hdr_shown=
if test -f "$GIT_DIR/info/exclude"
then
- git-ls-files -z --others $option \
+ git-ls-files --others $option \
--exclude-from="$GIT_DIR/info/exclude" \
--exclude-per-directory=.gitignore
else
- git-ls-files -z --others $option \
+ git-ls-files --others $option \
--exclude-per-directory=.gitignore
fi |
- @@PERL@@ -e '$/ = "\0";
- my $shown = 0;
- while (<>) {
- chomp;
- s|\\|\\\\|g;
- s|\t|\\t|g;
- s|\n|\\n|g;
- s/^/# /;
- if (!$shown) {
- print "#\n# Untracked files:\n";
- print "# (use \"git add\" to add to commit)\n";
- print "#\n";
- $shown = 1;
- }
- print "$_\n";
- }
- '
+ while read line; do
+ if [ -z "$hdr_shown" ]; then
+ echo '#'
+ echo '# Untracked files:'
+ echo '# (use "git add" to add to commit)'
+ echo '#'
+ hdr_shown=1
+ fi
+ echo "# $line"
+ done
if test -n "$verbose" -a -z "$IS_INITIAL"
then
--
1.4.1.gb4adf
^ permalink raw reply related
* Re: git-daemon problem
From: Andre Noll @ 2006-07-13 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git
In-Reply-To: <7vveq2ukho.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
On 22:44, Junio C Hamano wrote:
> The only "right" solution I could think of is to properly
> daemonize git-daemon when not running under --inetd mode. Close
> and open /dev/null the low three fds, and dissociate the process
> from the controlling terminal (did I forget anything else --
> perhaps chdir("/") at the top?). And we keep the current
> behaviour of assuming the sane set of low three fds when a new
> option --debug is given to help people look at its stderr. The
> tentative patch to upload-pack would become moot at that point.
>
> Hmm?
A common solution for this problem is
while (1) {
int fd;
fd = open("/dev/null", O_RDWR);
if (fd < 0)
exit(EX_OSERR);
if (fd > 2) {
close(fd);
break;
}
}
See
http://rechner.lst.de/~okir/blackhats/node41.html
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-daemon problem
From: Matthias Lederhofer @ 2006-07-13 11:51 UTC (permalink / raw)
To: git
In-Reply-To: <E1G0QeX-0003hG-0I@moooo.ath.cx>
Here are some patches that should solve this.
Note: The first patch is not really related to this problem but I
think the die error message should go to syslog when --syslog was
used. (And I did not have to add more if-clauses.)
Documentation will follow if the changes are ok.
^ permalink raw reply
* [PATCH 2/5] daemon: if one of the standard fds is missing open it to /dev/null
From: Matthias Lederhofer @ 2006-07-13 10:10 UTC (permalink / raw)
To: git
In-Reply-To: <E1G0zj7-0001c1-8q@moooo.ath.cx>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
daemon.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/daemon.c b/daemon.c
index a7636bc..e6b1730 100644
--- a/daemon.c
+++ b/daemon.c
@@ -662,6 +662,24 @@ static int service_loop(int socknum, int
}
}
+/* if any standard file descriptor is missing open it to /dev/null */
+static void sanitize_stdfds(void)
+{
+ int devnull = -1, i;
+ struct stat buf;
+ for (i = 0; i < 3; ++i) {
+ if (fstat(i, &buf) != -1)
+ continue;
+ if (devnull == -1 &&
+ (devnull = open("/dev/null", O_RDWR, 0)) == -1)
+ die("open /dev/null failed: %s", strerror(errno));
+ if (dup2(devnull, i) != i)
+ die("dup2 failed: %s", strerror(errno));
+ }
+ if (devnull != -1)
+ close(devnull);
+}
+
static int serve(int port)
{
int socknum, *socklist;
@@ -773,5 +791,7 @@ int main(int argc, char **argv)
return execute(peer);
}
+ sanitize_stdfds();
+
return serve(port);
}
--
1.4.1.gb16f
^ permalink raw reply related
* [PATCH 4/5] daemon: new option --pid-file=<path> to store the pid
From: Matthias Lederhofer @ 2006-07-13 10:18 UTC (permalink / raw)
To: git
In-Reply-To: <E1G0zj7-0001c1-8q@moooo.ath.cx>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
daemon.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/daemon.c b/daemon.c
index e6b1730..4b85930 100644
--- a/daemon.c
+++ b/daemon.c
@@ -680,6 +680,15 @@ static void sanitize_stdfds(void)
close(devnull);
}
+static void store_pid(const char *path)
+{
+ FILE *f = fopen(path, "w");
+ if (!f)
+ die("cannot open pid file %s: %s", path, strerror(errno));
+ fprintf(f, "%d\n", getpid());
+ fclose(f);
+}
+
static int serve(int port)
{
int socknum, *socklist;
@@ -695,6 +704,7 @@ int main(int argc, char **argv)
{
int port = DEFAULT_GIT_PORT;
int inetd_mode = 0;
+ const char *pid_file = NULL;
int i;
/* Without this we cannot rely on waitpid() to tell
@@ -759,6 +769,10 @@ int main(int argc, char **argv)
user_path = arg + 12;
continue;
}
+ if (!strncmp(arg, "--pid-file=", 11)) {
+ pid_file = arg + 11;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
@@ -793,5 +807,8 @@ int main(int argc, char **argv)
sanitize_stdfds();
+ if (pid_file)
+ store_pid(pid_file);
+
return serve(port);
}
--
1.4.1.gb16f
^ permalink raw reply related
* [PATCH 5/5] daemon: new option --detach to run git-daemon in background
From: Matthias Lederhofer @ 2006-07-13 10:32 UTC (permalink / raw)
To: git
In-Reply-To: <E1G0zj7-0001c1-8q@moooo.ath.cx>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
daemon.c | 32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/daemon.c b/daemon.c
index 4b85930..9f4bc20 100644
--- a/daemon.c
+++ b/daemon.c
@@ -662,6 +662,27 @@ static int service_loop(int socknum, int
}
}
+static void daemonize(void)
+{
+ int devnull = -1;
+ switch (fork()) {
+ case 0:
+ break;
+ case -1:
+ die("fork failed: %s", strerror(errno));
+ default:
+ exit(0);
+ }
+ if (setsid() == -1)
+ die("setsid failed: %s", strerror(errno));
+ if ((devnull = open("/dev/null", O_RDWR, 0)) == -1)
+ die("open /dev/null failed: %s", strerror(errno));
+ if (dup2(devnull, 0) != 0 ||
+ dup2(devnull, 1) != 1 ||
+ dup2(devnull, 2) != 2)
+ die("dup2 failed: %s", strerror(errno));
+}
+
/* if any standard file descriptor is missing open it to /dev/null */
static void sanitize_stdfds(void)
{
@@ -705,6 +726,7 @@ int main(int argc, char **argv)
int port = DEFAULT_GIT_PORT;
int inetd_mode = 0;
const char *pid_file = NULL;
+ int detach = 0;
int i;
/* Without this we cannot rely on waitpid() to tell
@@ -773,6 +795,11 @@ int main(int argc, char **argv)
pid_file = arg + 11;
continue;
}
+ if (!strcmp(arg, "--detach")) {
+ detach = 1;
+ log_syslog = 1;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
@@ -805,7 +832,10 @@ int main(int argc, char **argv)
return execute(peer);
}
- sanitize_stdfds();
+ if (detach)
+ daemonize();
+ else
+ sanitize_stdfds();
if (pid_file)
store_pid(pid_file);
--
1.4.1.gb16f
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox