* Re: [msysGit] Re: [PATCH 0/2] submodules: Use relative paths to gitdir and work tree
From: Johannes Sixt @ 2012-02-28 18:58 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Git Mailing List, Antony Male, Phil Hord, msysGit,
Johannes Schindelin
In-Reply-To: <4F4BF357.8020407@kdbg.org>
Am 27.02.2012 22:19, schrieb Johannes Sixt:
> Am 26.02.2012 20:58, schrieb Jens Lehmann:
>> I don't understand why you need this. Does "pwd" sometimes return a
>> path starting with "c:/" and sometimes "/c/" depending on what form
>> you use when you cd into that directory?
>
> It looks like this is the case. I was surprised as well. I hoped that
> pwd -P would fix it, but it makes no difference. I should have tested
> pwd -L as well, but I forgot.
pwd -L doesn't make a difference, either.
>> - gitdir=$(git rev-parse --git-dir)
>> + gitdir=$(git rev-parse --git-dir | sed -e 's,^\([a-z]\):/,/\1/,')
>
> I don't like pipelines of this kind because they fork yet another
> process. But it looks like there are not that many alternatives...
With the following patch on top of your always-use-relative-gitdir branch
from https://github.com/jlehmann/git-submod-enhancements the tests pass
on Windows.
Thanks, Dscho, for pointing out the obvious.
diff --git a/git-submodule.sh b/git-submodule.sh
index e1984e0..953ca5e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -151,6 +151,9 @@ module_clone()
a=$(cd "$gitdir" && pwd)
b=$(cd "$path" && pwd)
+ # normalize Windows-style absolute paths to POSIX-style absolute paths
+ case $a in [a-zA-Z]:/*) a=/${a%%:*}${a#*:} esac
+ case $b in [a-zA-Z]:/*) b=/${b%%:*}${b#*:} esac
# Remove all common leading directories
while test -n "$a" && test -n "$b" && test "${a%%/*}" = "${b%%/*}"
do
^ permalink raw reply related
* Re: [PATCH v7 05/10] column: add column.ui for default column output settings
From: Junio C Hamano @ 2012-02-28 18:44 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Ramsay Jones
In-Reply-To: <1330430331-19945-6-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +static int column_config(const char *var, const char *value,
> + const char *key, unsigned int *colopts)
> +{
> + if (git_config_column(colopts, value, -1))
Are we sure nobody has put us on pager at this point, so that you can tell
git_config_column() that it is OK to use isatty(1) to figure it out, or we
could already be on pager (i.e. pager_in_use() is true) in which case we
know we are interactive and should behave the same way as writing to a
terminal?
> + return error("invalid %s mode %s", key, value);
> + return 0;
> +}
> +
> +int git_column_config(const char *var, const char *value,
> + const char *command, unsigned int *colopts)
> +{
> + if (!strcmp(var, "column.ui"))
> + return column_config(var, value, "column.ui", colopts);
> +
> + if (command) {
> + struct strbuf sb = STRBUF_INIT;
> + int ret = 0;
> + strbuf_addf(&sb, "column.%s", command);
> + if (!strcmp(var, sb.buf))
> + ret = column_config(var, value, sb.buf, colopts);
> + strbuf_release(&sb);
> + return ret;
> + }
This feels wrong. Depending on the order column.ui and column.frotz appear
in the configuration file, asking for "git column --command=frotz" would
yield random results, no?
Shouldn't the flow of logic be more like:
git_config(git_column_config);
-> git_column_config() is called for column.ui and column.frotz
in no specified order; keep two *char variables to store the
string value given from configuration
if (kept value from column.frotz is missing)
git_config_column(..., kept value from column.ui, ...);
else
git_config_column(..., kept value from column.frotz, ...);
> diff --git a/column.h b/column.h
> index eb03c6c..43528da 100644
> --- a/column.h
> +++ b/column.h
> @@ -27,6 +27,8 @@ extern void print_columns(const struct string_list *list,
> struct column_options *opts);
> extern int git_config_column(unsigned int *mode, const char *value,
> int stdout_is_tty);
> +extern int git_column_config(const char *var, const char *value,
> + const char *command, unsigned int *colopts);
Also please rename git_config_column() in the earlier patch, perhaps like
"parse_column_config_string()" or something more sensible, to avoid
confusion.
^ permalink raw reply
* [PATCH (BUGFIX)] gitweb: Handle invalid regexp in regexp search
From: Jakub Narebski @ 2012-02-28 18:41 UTC (permalink / raw)
To: git; +Cc: Ramsay Jones
When using regexp search ('sr' parameter / $search_use_regexp variable
is true), check first that regexp is valid.
Without this patch we would get an error from Perl during search (if
searching is performed by gitweb), or highlighting matches substring
(if applicable), if user provided invalid regexp... which means broken
HTML, with error page (including HTTP headers) generated after gitweb
already produced some output.
Add test that illustrates such error: for example for regexp "*\.git"
we would get the following error:
Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE \.git/
at /var/www/cgi-bin/gitweb.cgi line 3084.
Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
See "Re: gitweb: (potential) problems with new installation"
http://thread.gmane.org/gmane.comp.version-control.git/191746
gitweb/gitweb.perl | 11 ++++++++++-
t/t9501-gitweb-standalone-http-status.sh | 10 ++++++++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1fc5361..22ad279 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1081,7 +1081,16 @@ sub evaluate_and_validate_params {
if (length($searchtext) < 2) {
die_error(403, "At least two characters are required for search parameter");
}
- $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
+ if ($search_use_regexp) {
+ $search_regexp = $searchtext;
+ if (!eval { qr/$search_regexp/; 1; }) {
+ (my $error = $@) =~ s/ at \S+ line \d+.*\n?//;
+ die_error(400, "Invalid search regexp '$search_regexp'",
+ esc_html($error));
+ }
+ } else {
+ $search_regexp = quotemeta $searchtext;
+ }
}
}
diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-standalone-http-status.sh
index 26102ee..31076ed 100755
--- a/t/t9501-gitweb-standalone-http-status.sh
+++ b/t/t9501-gitweb-standalone-http-status.sh
@@ -134,4 +134,14 @@ our $maxload = undef;
EOF
+# ----------------------------------------------------------------------
+# invalid arguments
+
+test_expect_success 'invalid arguments: invalid regexp (in project search)' '
+ gitweb_run "a=project_list;s=*\.git;sr=1" &&
+ grep "Status: 400" gitweb.headers &&
+ grep "400 - Invalid.*regexp" gitweb.body
+'
+test_debug 'cat gitweb.headers'
+
test_done
^ permalink raw reply related
* Re: [PATCH v7 04/10] column: add dense layout support
From: Junio C Hamano @ 2012-02-28 18:27 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Ramsay Jones
In-Reply-To: <1330430331-19945-5-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Normally, all items will be gone through once. The largest cell will set
> column width for all columns. With this strategy, one long item will
> stretch out all columns, wasting space in between them.
>
> With COL_DENSE enabled, it shrinks all columns to minimum, then attempts
> to push the last row's cells over to the next column with hope that
> everything still fits even there's one row less. The process is repeated
> until the new layout cannot fit in given width anymore, or there's only
> one row left (perfect!).
As you have given 4 bits for COL_MODE in the previous patch, I expected
that this will be one of the mode that you can use, e.g. column-first dense,
or row-first no-dense, with two more bits for operating modes. Not calling
it COL_MODE_DENSE and assigning a "are we dense of not?" bit out of COL_MODE
bits feels wrong.
^ permalink raw reply
* Re: [PATCH 1/3] http: authenticate on NTLM proxies and others suppported, by CuRL
From: Nelson Benitez Leon @ 2012-02-28 18:15 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, peff, sam, sam.vilain
In-Reply-To: <8762er6nb2.fsf@thomas.inf.ethz.ch>
On 02/28/2012 03:32 PM, Thomas Rast wrote:
> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
>
>> - if (curl_http_proxy)
>> + if (curl_http_proxy) {
>> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>> + curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>> + }
>
> There was another attempt at doing the same very recently:
>
> http://thread.gmane.org/gmane.comp.version-control.git/191140
>
> I could swear there was a second one, but apparently that was you.
> Neither you nor Marco submitter have so far answered the question I
> raised in
>
> http://thread.gmane.org/gmane.comp.version-control.git/191155
>
> which can be summarized as: please make a case -- and put it in the
> message! -- for or against making this configurable. Is there a speed
> tradeoff? (However, you could steal some of Daniel Stenberg's
> reasoning!)
I don't see any reason to make this configurable, CuRL people made this
cool CURLAUTH_ANY option that automatically chooses the best auth method
from among those the server supports, that means you don't have to
investigate if your proxy is using Basic, Digest or NTLM methods, and
use a specific curl option for each of them, instead curl
will ask the proxy and use the appropiate, and it will only do that if
you are using a proxy (i.e. you've set CURLOPT_PROXY or you have http_proxy
env var), also curl will not try to authenticate if you've not provided
username or password in the proxy string, as I've been told here[1]..
so, setting CURLOPT_PROXYAUTH = CURLAUTH_ANY will not affect the speed of
normal curl use, only if 1) you are using a proxy and 2) your proxy requires
authentication, only then curl will just make two or three roundtrips to find out
the auth method the proxy is using, that is a tiny cost compared to having the
user find out the proxy auth type and set an specifically config option to enable
that type.
So I would call CURLAUTH_ANY as out-of-the-box proxy support, and I don't want it
activated from a config option, I want it to still be out-of-the-box in git also..
[1] https://bugzilla.redhat.com/show_bug.cgi?id=769254#c6
^ permalink raw reply
* Re: [PATCH v7 03/10] column: add columnar layout
From: Junio C Hamano @ 2012-02-28 18:22 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Ramsay Jones
In-Reply-To: <1330430331-19945-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> COL_MODE_COLUMN and COL_MODE_ROW fill column by column (or row by row
> respectively), given the terminal width and how many space between
> columns.
>
> Strings are supposed to be in UTF-8. If strings contain ANSI escape
> strings, COL_ANSI must be specified for correct length calculation.
Hrm, is it too heavyweight to autodetect and relieve the caller from the
burden of passing COL_ANSI?
Perhaps if you update utf8_strwidth() so that it takes <ptr, len> input
not NUL terminated string, you can do item_length like this, no?
cp = s;
width = 0;
while (1) {
ep = strstr(cp, "\033[");
if (!ep) {
width += utf8_strwidth(cp);
break;
}
utf8_strwidth_counted(cp, ep - cp);
... scan ep to skip the "\033[...;X"
cp = ep;
}
^ permalink raw reply
* Re: [PATCH v7 02/10] Stop starting pager recursively
From: Junio C Hamano @ 2012-02-28 18:13 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Ramsay Jones
In-Reply-To: <1330430331-19945-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> git-column can be used as a pager for other git commands, something
> like this:
>
> GIT_PAGER="git -p column --mode='dense color'" git -p branch
>
> The problem with this is that "git -p column" also has $GIT_PAGER
> set so the pager runs itself again as a pager, then again and again.
>
> Stop this.
A natural question that may come after reading only the above is if "git
column" is the only one that has this problem. In other words, is the
undesirable behaviour you observed caused by a bug in setup_pager() that
needs to be fixed, or should it be fixed in "git column"?
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> pager.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/pager.c b/pager.c
> index 05584de..4dcb08d 100644
> --- a/pager.c
> +++ b/pager.c
> @@ -73,7 +73,7 @@ void setup_pager(void)
> {
> const char *pager = git_pager(isatty(1));
>
> - if (!pager)
> + if (!pager || pager_in_use())
> return;
>
> /*
^ permalink raw reply
* Re: [PATCH v7 01/10] Add git-column for columnar display
From: Junio C Hamano @ 2012-02-28 18:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Ramsay Jones
In-Reply-To: <1330430331-19945-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt
> new file mode 100644
> index 0000000..508b85f
> --- /dev/null
> +++ b/Documentation/git-column.txt
> @@ -0,0 +1,49 @@
> +git-column(1)
> +=============
> +
> +NAME
> +----
> +git-column - Display data in columns
> +
> +SYNOPSIS
> +--------
> +[verse]
> +'git column' [--mode=<mode> | --rawmode=<n>] [--width=<width>]
Please spell this "--raw-mode".
> diff --git a/builtin/column.c b/builtin/column.c
> new file mode 100644
> index 0000000..3b0f74e
> --- /dev/null
> +++ b/builtin/column.c
> @@ -0,0 +1,41 @@
> +#include "builtin.h"
> +#include "cache.h"
> +#include "strbuf.h"
> +#include "parse-options.h"
> +#include "string-list.h"
> +#include "column.h"
> +
> +static const char * const builtin_column_usage[] = {
> + "git column [options]",
> + NULL
> +};
> +static unsigned int colopts;
> +
> +int cmd_column(int argc, const char **argv, const char *prefix)
> +{
> + struct string_list list = STRING_LIST_INIT_DUP;
> + struct strbuf sb = STRBUF_INIT;
> + struct column_options copts;
> + struct option options[] = {
> + OPT_COLUMN(0, "mode", &colopts, "layout to use"),
> + OPT_INTEGER(0, "rawmode", &colopts, "layout to use"),
> + OPT_INTEGER(0, "width", &copts.width, "Maximum width"),
> + OPT_STRING(0, "indent", &copts.indent, "string", "Padding space on left border"),
> + OPT_INTEGER(0, "nl", &copts.nl, "Padding space on right border"),
> + OPT_INTEGER(0, "padding", &copts.padding, "Padding space between columns"),
> + OPT_END()
> + };
> +
> + memset(&copts, 0, sizeof(copts));
> + copts.width = term_columns();
> + copts.padding = 1;
> + argc = parse_options(argc, argv, "", options, builtin_column_usage, 0);
Curious. The usual pattern is to set up the built-in default, call
git_config() to override it with the configured values, and then call
parse_options() to override at the runtime. I see configuration callback
defined in column.c but no call to git_config() here?
> + if (argc)
> + usage_with_options(builtin_column_usage, options);
> +
> + while (!strbuf_getline(&sb, stdin, '\n'))
> + string_list_append(&list, sb.buf);
> +
> + print_columns(&list, colopts, &copts);
> + return 0;
> +}
> diff --git a/column.c b/column.c
> new file mode 100644
> index 0000000..d61da81
> --- /dev/null
> +++ b/column.c
> @@ -0,0 +1,170 @@
> +#include "cache.h"
> +#include "column.h"
> +#include "string-list.h"
> +#include "parse-options.h"
> +
> +#define MODE(mode) ((mode) & COL_MODE)
> +
> +/* Display without layout when COL_ENABLED is not set */
> +static void display_plain(const struct string_list *list,
> + const char *indent, const char *nl)
> +{
> + int i;
> +
> + for (i = 0; i < list->nr; i++)
> + printf("%s%s%s", indent, list->items[i].string, nl);
> +}
> +
> +void print_columns(const struct string_list *list, unsigned int mode,
> + struct column_options *opts)
> +{
> + const char *indent = "", *nl = "\n";
> + int padding = 1, width = term_columns();
> +
> + if (!list->nr)
> + return;
> + if (opts) {
> + if (opts->indent)
> + indent = opts->indent;
> + if (opts->nl)
> + nl = opts->nl;
> + if (opts->width)
> + width = opts->width;
> + padding = opts->padding;
> + }
> + if (width <= 1 || !(mode & COL_ENABLED)) {
Curious why this is "1". If your terminal is only 2 columns wide, you
wouldn't be able to show your list items in two columns as you would want
to have an inter-column gap, no?
> + display_plain(list, indent, nl);
> + return;
> + }
> + die("BUG: invalid mode %d", MODE(mode));
> +}
> +
> +struct colopt {
> + enum {
> + ENABLE,
> + MODE,
> + OPTION
> + } type;
> + const char *name;
> + int value;
> +};
> +
> +/*
> + * Set COL_ENABLED and COL_ENABLED_SET. If 'set' is -1, check if
> + * stdout is tty.
> + */
> +static int set_enable_bit(unsigned int *mode, int set, int stdout_is_tty)
> +{
Somehow it looks to me that this is setting the ENABLED bit, not enable
bit.
> + if (set < 0) { /* auto */
> + if (stdout_is_tty < 0)
> + stdout_is_tty = isatty(1);
> + set = stdout_is_tty || (pager_in_use() && pager_use_color);
Why does this have anything to do with the use of color?
> + }
> + if (set)
> + *mode = *mode | COL_ENABLED | COL_ENABLED_SET;
> + else
> + *mode = (*mode & ~COL_ENABLED) | COL_ENABLED_SET;
> + return 0;
> +}
OK, so we record the desired value (either COL_ENABLED or not) and the
fact that a call to set_enable_bit() function set it. Which implies that
this function must be called from only one codepath (either setting from
the configuration mechanism, or by parsing the command line option) but
not both. I guess this is only called from configuration codepath?
> +/*
> + * Set COL_MODE_*. mode is intially copied from column.ui. If
> + * COL_ENABLED_SET is not set, then neither 'always', 'never' nor
> + * 'auto' has been used. Default to 'always'.
> + */
> +static int set_mode(unsigned int *mode, unsigned int value)
> +{
> + *mode = (*mode & ~COL_MODE) | value;
> + if (!(*mode & COL_ENABLED_SET))
> + *mode |= COL_ENABLED | COL_ENABLED_SET;
> +
> + return 0;
> +}
I am *imagining* that "*mode" begins with some compiled-in default, then
git_config() will read from column.* variables and set "*mode" but not in
this codepath, and by the time command line option triggers this codepath,
we should have seen everything the config wants to tell us, so if the
config did not say anything (i.e. COL_ENABLED_SET is not set yet), we
force enable the feature (the user wanting it to operate in some mode is
an indication enough that the user wants to enable the machinery as a
whole). So this function is designed to be called from command line option
parsing, but never from the configuration parsing.
But the parse_option() function below calls this, which would mean it is
also for command line option parsing and not configuration parsing. The
same function however calls set_enable_bit() we saw earlier that can only
be called from configuration codepath. What is going on?
I am afraid that we do not have enough to judge if this is sane in this
patch, as there is no support for column.ui at this stage. Perhaps the
series is not structured well and has things that are not yet relevant in
early part of it. Sigh.
The remainder of the patch unreviewed.
^ permalink raw reply
* Re: git (commit|tag) atomicity
From: Jakub Narebski @ 2012-02-28 17:41 UTC (permalink / raw)
To: Jon Jagger; +Cc: git, Holger Hellmuth
In-Reply-To: <CADWOt=ig5=Bhhkjs9-wbm2djtwWPOfPGtYt9pH-U3YuQ+iyXzg@mail.gmail.com>
Jon Jagger <jon@jaggersoft.com> writes:
> On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> > On 28.02.2012 16:40, Jon Jagger wrote:
>>>
>>> I don't know a lot about git - I use it as a tool behind
>>> http://cyber-dojo.com
>>> which is an online coding dojo server.
>>> I have a quick question...
>>> If I do a
>>> git commit ....
>>> in one thread and a
>>> git tag | sort -g
>>> in another thread is the output of the git tag guaranteed to be atomic?
>>
>> Can a "git commit" add or remove tags? AFAIK it can't and so the two
>> commands don't conflict in any way.
>
> Sorry, I failed to ask the question I really wanted to ask...
>
> I mean in one thread
> git tag -m 'AAA' BBB HEAD
> and in another thread
> git tag | sort -g
>
> and the question is whether the output of the git tag|sort -g command
> is guaranteed to be from before the git tag -m... or from after the
> git tag -m... but not "interleaved" in any way....
Creating a tag or a commit is guaranteed to be atomic. Git first
atomically adds tag or a commit to object database (atomic file write)
as loose object, then atomically writes tag reference as loose tag
('.git/refs/tags/foo' file, containing SHA-1 id of newly created tag).
"git tag", which list all tags, recursively scans (reads) 'refs/tags/'
directory, so it could theoretically happen that if you have very
large number of loose (unpacked) tags, "git tag" might theoretically
list tag 'zzz' created after start of command, but not list 'aaa' tag
created after start of command.
But I am not sure... that probably depends on how opendir(3) and
readdir(3) works on given filesystem wrt. updates to opened directory.
I think VFS on Linux ensures that you see view of filesystem as it was
on opendir().
--
Jakub Narebski
^ permalink raw reply
* l10n: the maintaince of git-po repo
From: Jiang Xin @ 2012-02-28 17:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
I'm looking forward to the next git release with Chinese l10n, so that
I can start to rewrite my book on Git. ;-)
The maintaince of the git-po and git-po-zh_CN repositories so far:
git-po repository
-----------------
Location : https://github.com/gotgit/git-po
Fork from : https://github.com/git/git
Description: This is the Git l10n master repo, and is used to coordinate
works of l10n teams. L10n team leaders send pull requests
to this repo, while other l10n contributors should wok on
the language specified repository created by the l10n team
leader.
Typical commits:
- commit https://github.com/gotgit/git-po/commit/71eb878
merge the pull request sent from the Chinese l10n team leader.
- commit https://github.com/gotgit/git-po/commit/1d4ac88
l10n: Update git.pot (12 new messages)
- commit https://github.com/gotgit/git-po/commit/508d124
Merge branch 'master' of 'git.git' into git-po,
and will generate new po/git.pot in next commit.
- commit https://github.com/gotgit/git-po/commit/dce37b6
l10n: initial git.pot for 1.7.10 upcoming release
git-po-zh_CN repository
-----------------------
Location : https://github.com/jiangxin/git-po-zh_CN
Fork from : https://github.com/gotgit/git-po
Description: Git l10n for Simplified Chinese.
Typical commits:
- commit https://github.com/jiangxin/git-po-zh_CN/commit/7ac1c0a
l10n: update Chinese translation to the new git.po
- commit https://github.com/jiangxin/git-po-zh_CN/commit/0ad9e96
fix of Chinese translation
- commit https://github.com/jiangxin/git-po-zh_CN/commit/d4a8e00
fix of Chinese translation
- commit https://github.com/jiangxin/git-po-zh_CN/commit/c04f5ac
l10n: initial of zh_CN l10n
--
Jiang Xin
^ permalink raw reply
* Re: [PATCH] branch: don't assume the merge filter ref exists
From: Junio C Hamano @ 2012-02-28 17:32 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Jeff King, Bernhard Reutner-Fischer, git
In-Reply-To: <1330442090.691.9.camel@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> On Mon, 2012-02-27 at 14:43 -0500, Jeff King wrote:
>>
>> It looks like "bad object" generally comes from parse_object failing,
>> which makes sense. It either means object corruption or you fed a full
>> 40-char sha1 that didn't exist (which, if you are being that specific,
>> probably is an indication of broken-ness in your repository).
>
> Right. Another version of the fix I was playing with used parse_object
> after get_sha1 in opt_parse_merge_filter to make sure there that the
> objects did exist, so I copied that error message for this patch.
>
> I see Junio's already squashed this in, and it's certainly a better
> message.
Ok, so what I have is good for everybody. Will merge to "next" and soon
to "master" and "maint".
Thanks, both.
^ permalink raw reply
* Re: [PATCH 1/3] http: authenticate on NTLM proxies and others suppported, by CuRL
From: Thomas Rast @ 2012-02-28 17:30 UTC (permalink / raw)
To: Nelson Benitez Leon; +Cc: git, peff, sam, sam.vilain
In-Reply-To: <4F4D19CC.5030303@seap.minhap.es>
Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> On 02/28/2012 03:32 PM, Thomas Rast wrote:
>> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
>>
>>> - if (curl_http_proxy)
>>> + if (curl_http_proxy) {
>>> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>>> + curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>>> + }
>>
>> There was another attempt at doing the same very recently:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/191140
>>
>> I could swear there was a second one, but apparently that was you.
>> Neither you nor Marco submitter have so far answered the question I
>> raised in
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/191155
>>
>> which can be summarized as: please make a case -- and put it in the
>> message! -- for or against making this configurable. Is there a speed
>> tradeoff? (However, you could steal some of Daniel Stenberg's
>> reasoning!)
>
> I don't see any reason to make this configurable, [snip]
Sorry for not making this clear, but you don't have to explain it to me
in the list archives; rather, the commit message should sufficiently
take care of it. That is, I was objecting to your (lack of a) commit
message.
The argument you need to counter here is (Daniel explains this) curl
does an extra roundtrip to the proxy to determine which protocols work,
which is a little extra cost.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC PATCH 2a] pretty: detect missing \n\n in commit message
From: Junio C Hamano @ 2012-02-28 17:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, git
In-Reply-To: <5234ba4babd28d9430750d227d629b4d4386b131.1330425111.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> get_header()'s exit condition is finding the \n\n that separates the
> commit header from its message. If such a double newline is not
> present, it segfaults. Catch this case and die().
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> This would be the minimal fix to the pretty machinery so that 'git
> rev-list --pretty=something HEAD' works when there are such broken
> commits.
>
> If 2b goes in, there isn't really any point as we would never get this
> far on such a commit.
>
>
> pretty.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/pretty.c b/pretty.c
> index 8688b8f..b7f097d 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -440,7 +440,10 @@ static char *get_header(const struct commit *commit, const char *key)
> const char *line = commit->buffer;
>
> for (;;) {
> - const char *eol = strchr(line, '\n'), *next;
> + const char *eol, *next;
> + if (!line)
> + die (_("malformed commit object: no separating \\n\\n?"));
> + eol = strchr(line, '\n');
The same comment applies here.
You can just return NULL in this case, I suppose?
> if (line == eol)
> return NULL;
^ permalink raw reply
* Re: [PATCH v2] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message
From: Junio C Hamano @ 2012-02-28 17:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, git
In-Reply-To: <010901fbfffe0f806bb19d556ebc1e512a4697f4.1330425111.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 3714582..5e9a832 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -690,7 +690,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
> hook_arg1 = "message";
> } else if (use_message) {
> buffer = strstr(use_message_buffer, "\n\n");
> - if (!buffer || buffer[2] == '\0')
> + if (!buffer)
> + die(_("commit object has invalid format"));
In line with my previous comment, I think this should be more like:
if (!buffer) {
static char v_o_i_d[] = "\n\n";
buffer = v_o_i_d;
warning(_("commit lacks end-of-header. A broken Git emulation?"");
}
The warning is of course optional.
^ permalink raw reply
* Re: gitweb: (potential) problems with new installation
From: Jakub Narebski @ 2012-02-28 17:25 UTC (permalink / raw)
To: git; +Cc: Ramsay Jones
[Cc-ed to git mailing list, again this time without HTML]
On Mon, 27 Feb 2012, Ramsay Jones wrote:
> I recently decided to update the gitweb installation on my laptop, since
> it was still running version 1.5.5! (also, the cgit I have installed is
> about the same vintage ...)
>
> The version of gitweb I installed was, simply because I had just built
> and tested it, the version included in the pu branch as of a couple of
> days ago (commit 8544a26).
>
> First, I should say that I had to modify the script, and move the static
> directory out of cgi-bin, in order to get it to work.
You should never have to modify generated gitweb.cgi script; that is what
configuration file, gitweb_config.perl by default, is for. It is well
documented in gitweb.conf(5) manpage, which in turn is referenced in
gitweb(1) manpage... at least with modern git.
Note also that you can specify where to put static files (page
prerequisites) during "make install"... though that it would not obviate
need to create and edit gitweb configuration file.
> However, this is
> not something new; I had to do the same with the previous version. The
> problem is obviously an apache configuration problem, which I tried to
> fix last time and (having spent *lots* of effort) gave up on; the main
> symptom of the problem is that apache attempts to *exec* any file in
> cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which
> fills up the apache error logs with "permission denied" errors while
> trying to exec.
Strange. Which version of Apache are you using, and how do relevant
parts of Apache configuration (httpd.conf etc.) look like?
If you use ScriptAlias directive, or ExecCGI option, then the problem
might be executable permissions -- Apache shouldn't execute scripts
without execute permission set as CGI scripts... errr... are you running
httpd as root?
You can move to using "AddHandler cgi-script .cgi" instead.
>
> Anyway, I moved the static directory into a gitweb directory (as a sibling
> to cgi-bin) and changed the paths in gitweb.cgi by prefixing "../gitweb/".
>
> Now that I had working gitweb, I played with some of the new features and
> noticed a few problems ... I suspect that most of the problems are caused
> by my *old* version of firefox, which is:
>
> firefox version 2.0.0.3
>
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) \
> Gecko/20061201 Firefox/2.0.0.3
I have even older web browser:
Mozilla 1.7.12
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) \
Gecko/20050923 MultiZilla/1.7.9.0a
> However, I hope the following may be of use; even if only to document a
> version of firefox that is not supported by gitweb. ;-)
>
> 1. The new date timezone pop-up; The pop-up window comes up directly
> over the date, so you can no longer read it, and once you have set
> the desired timezone, it can not be dismissed. (including the x
> button on the window). The only way to remove it is to refresh the
> page, which makes it a little less that useful ... :-D
Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time
of writing Firefox, Chrome, IE, and ancient Konqueror without encountering
any problems.
Could you at minimum check for JavaScript errors using JavaScript Console
(clearing it and reloading gitweb page if needed)? Please provide line
where error is with a bit of context (around 3 lines).
Note also that as workaround you can simply turn off this feature: put
the following line in gitweb configuration file:
$feature{'javascript-timezone'}{'default'} = [];
> 2. The error console shows a repeated warning about the css file, like
> so:
>
> Warning: Error in parsing value for property 'display'. \
> Declaration dropped.
> Source File: http://localhost/gitweb/static/gitweb.css
> Line: 621
>
> which corresponds to the following in gitweb.css:
>
> div.remote {
> margin: .5em;
> border: 1px solid #d9d8d1;
> display: inline-block; <-- line 621
> }
This is probably caused by the fact that your web browser doesn't
understand this value of 'display' property because it is too old,
and does not implement CSS2.1 fully.
9.2.4 The 'display' property
inline-block
This value causes an element to generate an inline-level block
container. The inside of an inline-block is formatted as a block
box, and the element itself is formatted as an atomic inline-level
box.
Nb. this is probably not necessary, gitweb looks just fine without it.
> 3. I mis-typed an search term into the project search box and didn't
> see the error message displayed by firefox as I expected (maybe
> incorrectly?). Firefox displayed:
>
> XML Parsing Error: xml declaration not at start of external entity
> Location: http://localhost/cgi-bin/gitweb.cgi?a=project_list&\
> s=*git.*%5C.git&btnS=Search
> Line Number 30, Column 1:
> <?xml version="1.0" encoding="utf-8"?>
> ^
It is the problem with older Firefoxes, namely that with XHTML DTD and
with application/xhtml+xml mimetype it enters strict XML compliance mode.
If webpage is not well-formed XML it would display XML error page instead.
It is enough that there is some whitespace before <?xml ... ?> processing
instruction... which might make for intermittent and annoying to squash
Heisenbug.
But in some cases it might happen if there are warnings or errors created
by Perl itself and converted to web page by CGI::Carp (fatalsToBrowser).
> The apache error log looked correct:
>
> [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \
> in regex; marked by <-- HERE in m/* <-- HERE git.*\.git/ at \
> /var/www/cgi-bin/gitweb.cgi line 3084.
Hmmm... if we don't use regexp search, then all metacharacters should be
quoted, including leading '*'. Strange.
If you did use regexp search, then it is a real issue, and it is not
something I have thought about. Your search term
*git.*\.git
is invalid regexp, because '*' quantifier which means zero or more
occurrences does not follow any term. Valid regexp is
.*git.*\.git
or just
git.*\.git
Gitweb should probably check that regexp is valid before using it.
Thanks for reporting this; I'll try to fix it shortly.
> Whereas the page source did look wrong. Just in case it would be of
> use, I have included the page source below.
Thanks.
Damn, I thought that I have that issue squashed! The problem is when
there is error thrown or warning triggered when gitweb already printed
part of page. The error handler then writes error page from beginning
inside existing page... not good.
I'll try to look at this.
> As I said above, I suspect these problems are caused by my relatively old
> Linux installation (I keep meaning to get around to updating, but I must
> say that I don't like the new Ubuntu, although Linux Mint 12 looks quite
> good ...).
>
> Having said that, ignoring the new features, gitweb is working fine for
> me (I only installed it in the first place to test it out ...). Also, the
> above represents (literally) only ten minutes of playing around with the
> new features, without having read any documentation or code. So, if I have
> mis-understood how something should work, then sorry for the noise! :(
>
> Hope this helps.
>
> ATB,
> Ramsay Jones
[cut example HTML output]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message
From: Junio C Hamano @ 2012-02-28 17:21 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Thomas Rast, git
In-Reply-To: <87haybco1j.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> writes:
> So either there's a lot to be fixed, or fsck needs to catch this.
Your experiment with hash-object aside (that is like saying "I can write
garbage with a disk editor, and now OS cannot read from that directory"),
if somebody manages to create a commit without any body, it is clear that
the user wanted to record no body. I think all code that tries to run
strstr("\n\n") and increment the resulting pointer by two to find the
beginning of the body should behave as if it found one and the result
pointed at a NUL. Rejecting with fsck does not help anybody, as it
happens after the fact.
^ permalink raw reply
* Re: git (commit|tag) atomicity
From: Jon Jagger @ 2012-02-28 17:12 UTC (permalink / raw)
To: git
In-Reply-To: <4F4D04F4.80905@ira.uka.de>
On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> On 28.02.2012 16:40, Jon Jagger wrote:
>>
>> Hi,
>> I don't know a lot about git - I use it as a tool behind
>> http://cyber-dojo.com
>> which is an online coding dojo server.
>> I have a quick question...
>> If I do a
>> git commit ....
>> in one thread and a
>> git tag | sort -g
>> in another thread is the output of the git tag guaranteed to be atomic?
>
>
> Can a "git commit" add or remove tags? AFAIK it can't and so the two
> commands don't conflict in any way.
Sorry, I failed to ask the question I really wanted to ask...
I mean in one thread
git tag -m 'AAA' BBB HEAD
and in another thread
git tag | sort -g
and the question is whether the output of the git tag|sort -g command
is guaranteed to be from before the git tag -m... or from after the
git tag -m... but not "interleaved" in any way....
Cheers
Jon
^ permalink raw reply
* Re: git (commit|tag) atomicity
From: Holger Hellmuth @ 2012-02-28 16:46 UTC (permalink / raw)
To: Jon Jagger; +Cc: git
In-Reply-To: <CADWOt=j8gJvr88eNAfoYq_qGQvG6M_k-9MCuof_DRrH0sHRVCA@mail.gmail.com>
On 28.02.2012 16:40, Jon Jagger wrote:
> Hi,
> I don't know a lot about git - I use it as a tool behind
> http://cyber-dojo.com
> which is an online coding dojo server.
> I have a quick question...
> If I do a
> git commit ....
> in one thread and a
> git tag | sort -g
> in another thread is the output of the git tag guaranteed to be atomic?
Can a "git commit" add or remove tags? AFAIK it can't and so the two
commands don't conflict in any way.
^ permalink raw reply
* Re: [PATCH v2] Perform cheaper connectivity check when pack is used as medium
From: Andreas Ericsson @ 2012-02-28 15:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano
In-Reply-To: <4F4CF58A.9090502@viscovery.net>
On 02/28/2012 04:40 PM, Johannes Sixt wrote:
> Am 2/28/2012 14:18, schrieb Nguyễn Thái Ngọc Duy:
>> Without the patch:
>> $ time git fetch file:///home/pclouds/w/git/.git
>> remote: Counting objects: 125638, done.
>> remote: Compressing objects: 100% (33201/33201), done.
> ...
>> With the patch:
>> $ time git fetch file:///home/pclouds/w/git/.git
>> remote: Counting objects: 125647, done.
>> remote: Compressing objects: 100% (33209/33209), done.
>
> It is a bit irritating that the number are different when they should be
> identical...
>
I found it odd as well, but since the latter shows a larger object
count and a shorter time, I disregarded it and considered it some
evidence that he pushed this patch to that repo.
Since commit created 6 blobs, 2 trees and 1 commit object, and the
latter has 9 objects more, I assume that's what happened anyways.
As such, I think we can live with the small discrepancy. Also note
that the latter post had slower transfer rate. That also skews the
comparison somewhat, but again it's in favour of the patch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH v2] Perform cheaper connectivity check when pack is used as medium
From: Johannes Sixt @ 2012-02-28 15:40 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1330435109-4437-1-git-send-email-pclouds@gmail.com>
Am 2/28/2012 14:18, schrieb Nguyễn Thái Ngọc Duy:
> Without the patch:
> $ time git fetch file:///home/pclouds/w/git/.git
> remote: Counting objects: 125638, done.
> remote: Compressing objects: 100% (33201/33201), done.
...
> With the patch:
> $ time git fetch file:///home/pclouds/w/git/.git
> remote: Counting objects: 125647, done.
> remote: Compressing objects: 100% (33209/33209), done.
It is a bit irritating that the number are different when they should be
identical...
-- Hannes
^ permalink raw reply
* git (commit|tag) atomicity
From: Jon Jagger @ 2012-02-28 15:40 UTC (permalink / raw)
To: git
Hi,
I don't know a lot about git - I use it as a tool behind
http://cyber-dojo.com
which is an online coding dojo server.
I have a quick question...
If I do a
git commit ....
in one thread and a
git tag | sort -g
in another thread is the output of the git tag guaranteed to be atomic?
That is, the output will be from before the git commit or after it but
not a mixture?
Logically, I assume so but cannot find anything definitive on google
or in my git books or from the lips of my friends.
Thanks for any help
Jon Jagger
^ permalink raw reply
* [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed
From: Carlos Martín Nieto @ 2012-02-28 15:35 UTC (permalink / raw)
To: git
Text between to '*' is emphasized in AsciiDoc which made the
glob-related explanations in rev-list-options.txt very confusing, as
the rendered text would be missing two asterisks and the text between
them would be emphasized instead.
Use '{asterisk}' where needed to make them show up as asterisks in the
rendered text.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
Documentation/rev-list-options.txt | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 39e6207..6a4b635 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -117,27 +117,27 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
Pretend as if all the refs in `refs/heads` are listed
on the command line as '<commit>'. If '<pattern>' is given, limit
branches to ones matching given shell glob. If pattern lacks '?',
- '*', or '[', '/*' at the end is implied.
+ '{asterisk}', or '[', '/{asterisk}' at the end is implied.
--tags[=<pattern>]::
Pretend as if all the refs in `refs/tags` are listed
on the command line as '<commit>'. If '<pattern>' is given, limit
- tags to ones matching given shell glob. If pattern lacks '?', '*',
- or '[', '/*' at the end is implied.
+ tags to ones matching given shell glob. If pattern lacks '?', '{asterisk}',
+ or '[', '/{asterisk}' at the end is implied.
--remotes[=<pattern>]::
Pretend as if all the refs in `refs/remotes` are listed
on the command line as '<commit>'. If '<pattern>' is given, limit
remote-tracking branches to ones matching given shell glob.
- If pattern lacks '?', '*', or '[', '/*' at the end is implied.
+ If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied.
--glob=<glob-pattern>::
Pretend as if all the refs matching shell glob '<glob-pattern>'
are listed on the command line as '<commit>'. Leading 'refs/',
- is automatically prepended if missing. If pattern lacks '?', '*',
- or '[', '/*' at the end is implied.
+ is automatically prepended if missing. If pattern lacks '?', '{asterisk}',
+ or '[', '/{asterisk}' at the end is implied.
--ignore-missing::
--
1.7.9.2.3.g4346f
^ permalink raw reply related
* Re: [PATCH] branch: don't assume the merge filter ref exists
From: Carlos Martín Nieto @ 2012-02-28 15:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Bernhard Reutner-Fischer, git
In-Reply-To: <20120227194305.GE1600@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Mon, 2012-02-27 at 14:43 -0500, Jeff King wrote:
> On Mon, Feb 27, 2012 at 11:33:49AM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > You would also get NULL if the object exists but is not a commit. Maybe:
> > >
> > > die("object '%s' does not point to a commit", ...)
> > >
> > > would be better? It covers the wrong-type case, and is still technically
> > > true when the object does not exist.
> >
> > For this particular message I like the above a lot better. The output
> > from "git grep -e 'invalid object' -e 'bad object'" seems to show that
> > the use of both are fairly evenly distributed.
>
> It looks like "bad object" generally comes from parse_object failing,
> which makes sense. It either means object corruption or you fed a full
> 40-char sha1 that didn't exist (which, if you are being that specific,
> probably is an indication of broken-ness in your repository).
Right. Another version of the fix I was playing with used parse_object
after get_sha1 in opt_parse_merge_filter to make sure there that the
objects did exist, so I copied that error message for this patch.
I see Junio's already squashed this in, and it's certainly a better
message.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Thomas Rast @ 2012-02-28 14:34 UTC (permalink / raw)
To: Nelson Benitez Leon; +Cc: git, peff, sam.vilain, sam
In-Reply-To: <4F4CEB5D.5020808@seap.minhap.es>
Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> On 02/28/2012 01:19 PM, Thomas Rast wrote:
>>
>> * Why is this needed? Does git's use of libcurl ignore http_proxy? [1]
>> seems to indicate that libcurl respects <protocol>_proxy
>> automatically.
>
> It could not be needed, because, as you noted, curl already reads it, but then we will
> loose the feature on patch [3/3] because if $http_proxy has username but no password
> curl will not ask you for the password.. instead if we read it we could detect that,
> and ask for the password.
Ok. An explanation along these lines should definitely go into the
commit message!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/3] http: authenticate on NTLM proxies and others suppported, by CuRL
From: Thomas Rast @ 2012-02-28 14:32 UTC (permalink / raw)
To: Nelson Benitez Leon; +Cc: git, peff, sam, sam.vilain
In-Reply-To: <4F4CCE01.8080300@seap.minhap.es>
Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> - if (curl_http_proxy)
> + if (curl_http_proxy) {
> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
> + curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
> + }
There was another attempt at doing the same very recently:
http://thread.gmane.org/gmane.comp.version-control.git/191140
I could swear there was a second one, but apparently that was you.
Neither you nor Marco submitter have so far answered the question I
raised in
http://thread.gmane.org/gmane.comp.version-control.git/191155
which can be summarized as: please make a case -- and put it in the
message! -- for or against making this configurable. Is there a speed
tradeoff? (However, you could steal some of Daniel Stenberg's
reasoning!)
Note that Marco (the submitter in the first one) has told me privately
that he could not pursue this further right now, so I suppose he'd be
happy if you could finish it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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