* Re: Git, Parrot, Perl6, Rakudo for G4 MAC
From: Hilco Wijbenga @ 2011-11-15 17:51 UTC (permalink / raw)
To: Greg; +Cc: git
In-Reply-To: <loom.20111115T112500-386@post.gmane.org>
On 15 November 2011 02:36, Greg <greggallen@gmail.com> wrote:
> Could someone please assist me in locating the resources to "GIT"
> this stuff going on a G4 MAC PPC? I
> keep getting weird bugs.
> Need me to be more explicit? Ok - it says gcc v3.3 isn't compatible, and a
> bunch of other sheet!
GCC 3.3 is from May 2003, I suggest you upgrade to a more recent GCC
(probably 4.6).
> I already have Perl5.10.1 working fine, and performing
> numerous marvelous tasks, so I (perhaps
> mistakenly) thought it would be an easy addition.
Perl 5.10.1 is from August 2009. Presumably less of a problem but,
again, you should probably upgrade to something more recent.
(Please note that I don't know the minimum requirements in this regard
for Git. It's just that your tools are old to ancient. :-) )
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Erik Faye-Lund @ 2011-11-15 17:44 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Franck Bui-Huu, git, gitster, j6t, rene.scharfe
In-Reply-To: <20111115173715.GA4478@sigill.intra.peff.net>
On Tue, Nov 15, 2011 at 6:37 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 15, 2011 at 01:11:46PM +0100, Thomas Rast wrote:
>
>> But after a closer look I think this patch just prodded it enough to
>> unearth long-existing undefined behaviour: prepare_argv() summarizes
>> to something like
>>
>> static void prepare_argv(const char **sent_argv, const char **argv)
>> {
>> char *p, buf[4096];
>>
>> for (p = buf;;) {
>> len = packet_read_line(0, p, (buf + sizeof buf) - p);
>> /* ... p always points into buf ... */
>> sent_argv[sent_argc++] = p;
>> p += len;
>> *p++ = 0;
>> }
>> sent_argv[sent_argc] = NULL;
>> }
>>
>> The code appears to have looked like this ever since the addition of
>> that file back in 39345a2 (Add git-upload-archive, 2006-09-07). So
>> the elements of sent_argv have apparently always pointed into the
>> stack-allocated 'buf'.
>
> Oh, yikes. That is definitely the problem, but it does come from
> c09cd77e. The prepare_argv function used to be "run_upload_archive", and
> it would prepare argv on the stack, call into write_archive with it, and
> then return; nobody else cares about the value afterwards.
>
> Erik's patch converts it into a function that writes the new argv into a
> parameter and returns, and the now-invalid stack-allocated memory is
> used by the calling function.
>
Outch. Thanks for spotting.
>> A quick band-aid would be to heap-allocate it instead:
>
> That works. An even shorter band-aid is to mark it as "static".
Hmm, I seem to remember spotting it myself at some point and fixing it
by marking it as static. I guess I must have forgot to push it...
> I think the code would be more readable if it just used the new
> argv_array.
>
Oooh, nice. The whole argv_array slipped past me, I like it!
^ permalink raw reply
* Re: input director not compatible with git right-click
From: Carlos Martín Nieto @ 2011-11-15 17:38 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Eric, git
In-Reply-To: <CAMK1S_jWcLQTqzqQcAMk8PjZ4ir7Y7a8QY=JvmX2qbQnzJO4ew@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
On Tue, Nov 15, 2011 at 09:39:25PM +0530, Sitaram Chamarty wrote:
> On Mon, Nov 14, 2011 at 8:10 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> > On Sun, Nov 13, 2011 at 04:34:26PM +0000, Eric wrote:
> >> Hi,
> >>
> >> New in Git use, I use it do dev on window some administrative script. I use as
> >> well Input director to share keyboard and mouse on multiple computer.
> >
> > Do you mean you're using it on the Windows OS?
> >
> >>
> >> when I right-clicked on an item, it works when input director is disabled. If
> >
> > Right-click on what? git doesn't have a graphical interface. If you're
> > using a graphical front-end to git, you should send them a bug report.
>
> git comes with 3 perfectly cromulent graphical programs, and one of
> them is indispensable.
I guess we have diferent ideas of where "git" ends and other stuff
starts. gitk, git-gui and what is the last one?
>
> The real reason the original question is not meaningful here is that
> -- if he hadn't mentioned "share keyboard and mouse on multiple
> computer" most people would have no clue what the heck it was, and
> obscure software does... obscure things, so it should be reported to
> them. not here.
>
> --
> Sitaram
>
--
Carlos Martín Nieto | http://cmartin.tk
"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Jeff King @ 2011-11-15 17:37 UTC (permalink / raw)
To: Thomas Rast
Cc: Franck Bui-Huu, Erik Faye-Lund, git, gitster, j6t, rene.scharfe
In-Reply-To: <201111151311.46832.trast@student.ethz.ch>
On Tue, Nov 15, 2011 at 01:11:46PM +0100, Thomas Rast wrote:
> But after a closer look I think this patch just prodded it enough to
> unearth long-existing undefined behaviour: prepare_argv() summarizes
> to something like
>
> static void prepare_argv(const char **sent_argv, const char **argv)
> {
> char *p, buf[4096];
>
> for (p = buf;;) {
> len = packet_read_line(0, p, (buf + sizeof buf) - p);
> /* ... p always points into buf ... */
> sent_argv[sent_argc++] = p;
> p += len;
> *p++ = 0;
> }
> sent_argv[sent_argc] = NULL;
> }
>
> The code appears to have looked like this ever since the addition of
> that file back in 39345a2 (Add git-upload-archive, 2006-09-07). So
> the elements of sent_argv have apparently always pointed into the
> stack-allocated 'buf'.
Oh, yikes. That is definitely the problem, but it does come from
c09cd77e. The prepare_argv function used to be "run_upload_archive", and
it would prepare argv on the stack, call into write_archive with it, and
then return; nobody else cares about the value afterwards.
Erik's patch converts it into a function that writes the new argv into a
parameter and returns, and the now-invalid stack-allocated memory is
used by the calling function.
> A quick band-aid would be to heap-allocate it instead:
That works. An even shorter band-aid is to mark it as "static".
I think the code would be more readable if it just used the new
argv_array.
Junio, this bug is in 1.7.8-rc*. Do you want the one-liner fix for the
release, or the nicer fix?
-Peff
^ permalink raw reply
* [PATCH 5/4] git-compat-util: don't assume value for undefined variable
From: Ramkumar Ramachandra @ 2011-11-15 17:31 UTC (permalink / raw)
To: Git List; +Cc: Thomas Rast
In-Reply-To: <1321376379-31750-1-git-send-email-artagnon@gmail.com>
Suggested-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
And here's another probably worth fixing.
git-compat-util.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5ef8ff7..8b4dd5c 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -219,7 +219,7 @@ extern char *gitbasename(char *);
#define find_last_dir_sep(path) strrchr(path, '/')
#endif
-#if __HP_cc >= 61000
+#if defined(__HP_cc) && (__HP_cc >= 61000)
#define NORETURN __attribute__((noreturn))
#define NORETURN_PTR
#elif defined(__GNUC__) && !defined(NO_NORETURN)
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply related
* [PATCH 4/4] sha1_file: don't mix enum with int
From: Ramkumar Ramachandra @ 2011-11-15 16:59 UTC (permalink / raw)
To: Git List; +Cc: Thomas Rast
In-Reply-To: <1321376379-31750-1-git-send-email-artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 27f3b9b..869852b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2616,7 +2616,7 @@ static int index_mem(unsigned char *sha1, void *buf, size_t size,
if ((type == OBJ_BLOB) && path) {
struct strbuf nbuf = STRBUF_INIT;
if (convert_to_git(path, buf, size, &nbuf,
- write_object ? safe_crlf : 0)) {
+ write_object ? safe_crlf : SAFE_CRLF_FALSE)) {
buf = strbuf_detach(&nbuf, &size);
re_allocated = 1;
}
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply related
* [PATCH 3/4] ll-merge: initialize default_opts const
From: Ramkumar Ramachandra @ 2011-11-15 16:59 UTC (permalink / raw)
To: Git List; +Cc: Thomas Rast
In-Reply-To: <1321376379-31750-1-git-send-email-artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
ll-merge.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ll-merge.c b/ll-merge.c
index da59738..205aed3 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -351,7 +351,7 @@ int ll_merge(mmbuffer_t *result_buf,
const struct ll_merge_options *opts)
{
static struct git_attr_check check[2];
- static const struct ll_merge_options default_opts;
+ static const struct ll_merge_options default_opts = {0, 0, 0, 0};
const char *ll_driver_name = NULL;
int marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
const struct ll_merge_driver *driver;
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply related
* [PATCH 1/4] http: remove unused function hex()
From: Ramkumar Ramachandra @ 2011-11-15 16:59 UTC (permalink / raw)
To: Git List; +Cc: Thomas Rast
In-Reply-To: <1321376379-31750-1-git-send-email-artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
http.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/http.c b/http.c
index 008ad72..e6c7597 100644
--- a/http.c
+++ b/http.c
@@ -747,14 +747,6 @@ static inline int needs_quote(int ch)
return 1;
}
-static inline int hex(int v)
-{
- if (v < 10)
- return '0' + v;
- else
- return 'A' + v - 10;
-}
-
static char *quote_ref_url(const char *base, const char *ref)
{
struct strbuf buf = STRBUF_INIT;
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply related
* [PATCH 2/4] convert: don't mix enum with int
From: Ramkumar Ramachandra @ 2011-11-15 16:59 UTC (permalink / raw)
To: Git List; +Cc: Thomas Rast
In-Reply-To: <1321376379-31750-1-git-send-email-artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
convert.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/convert.c b/convert.c
index 3bb5a4d..038b0be 100644
--- a/convert.c
+++ b/convert.c
@@ -641,7 +641,7 @@ static int ident_to_worktree(const char *path, const char *src, size_t len,
return 1;
}
-static int git_path_check_crlf(const char *path, struct git_attr_check *check)
+static enum crlf_action git_path_check_crlf(const char *path, struct git_attr_check *check)
{
const char *value = check->value;
@@ -658,7 +658,7 @@ static int git_path_check_crlf(const char *path, struct git_attr_check *check)
return CRLF_GUESS;
}
-static int git_path_check_eol(const char *path, struct git_attr_check *check)
+static enum crlf_action git_path_check_eol(const char *path, struct git_attr_check *check)
{
const char *value = check->value;
@@ -811,7 +811,7 @@ int renormalize_buffer(const char *path, const char *src, size_t len, struct str
src = dst->buf;
len = dst->len;
}
- return ret | convert_to_git(path, src, len, dst, 0);
+ return ret | convert_to_git(path, src, len, dst, SAFE_CRLF_FALSE);
}
/*****************************************************************
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply related
* [PATCH 0/4] Fix minor warnings reported by icc
From: Ramkumar Ramachandra @ 2011-11-15 16:59 UTC (permalink / raw)
To: Git List; +Cc: Thomas Rast
Hi,
Thomas Rast tried compiling Git with Intel's C compiler (icc) recently
and the results can be found here [1]. Most of them don't amount to
anything, are probably not worth fixing. Here are fixes to a few that
caught my eye.
Thanks.
[1]: https://gist.github.com/1367335
-- Ram
Ramkumar Ramachandra (4):
http: remove unused function hex()
convert: don't mix enum with int
ll-merge: initialize default_opts const
sha1_file: don't mix enum with int
convert.c | 6 +++---
http.c | 8 --------
ll-merge.c | 2 +-
sha1_file.c | 2 +-
4 files changed, 5 insertions(+), 13 deletions(-)
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply
* Re: [PATCH 3/5] sequencer: sequencer state is useless without todo
From: Junio C Hamano @ 2011-11-15 16:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <20111115095225.GB23139@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Ramkumar Ramachandra wrote:
>
>> Yeah, git_path() writes to one of the four static buffers in
>> path.c:get_pathname(). Which brings me to: what should (can) we do
>> about it?
>
> Just use a sane idiom. Which means: as few git_path() values in
> flight at a time as possible.
>
> In other words, do not save the git_path() result in a variable, but
> pass it directly to whatever computation needs to use it.
Or perhaps http://thread.gmane.org/gmane.comp.version-control.git/184963/focus=185436
^ permalink raw reply
* Re: [PATCH] Fix "is_refname_available(): query only possibly-conflicting references"
From: Michael Haggerty @ 2011-11-15 16:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <7vty65x2zl.fsf@alter.siamese.dyndns.org>
On 11/15/2011 08:24 AM, Junio C Hamano wrote:
> However, I'd rather see us spend effort to make absolutely sure that other
> topics already in next that touch the related codepaths (I think you have
> two such series yourself and I suspect there are other minor fixes that
> may textually conflict) are in good shape and have them graduate early
> after 1.7.8 ships, before queuing a re-roll of the ref-api series, which
> is rather extensive.
If you have a preference for which patch series you would like to
integrate in which order (and especially if you think that there are
gaps that need to be filled), please let me know. It would be a lot
less work to put them in the right order from the start rather than
trying to keep them all synchronized with master and continually reroll
them based on what you have merged so far.
Also, I am working under the assumption that the patch series that are
already in "next" should be left alone; if you have doubts about any of
those patch series (i.e., are thinking of ejecting them from next during
the post-release chaos), please let me know what needs changing.
I'm still getting the hang of this workflow, so suggestions are welcome.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 0/7] New sequencer workflow!
From: Ramkumar Ramachandra @ 2011-11-15 16:12 UTC (permalink / raw)
To: Phil Hord; +Cc: Git List, Junio C Hamano, Jonathan Nieder, Christian Couder
In-Reply-To: <CABURp0qt+r09Uy_nfLd60pXiMMXgTOUB__XL-N=S7HaJa-oWoA@mail.gmail.com>
Hi Phil,
Phil Hord wrote:
> I see that --reset was added to cherry-pick, revert and sequencer
> around the same time back in August. Shouldn't it be spelled
> "--abort" instead?
"reset" is actually different from "abort": it simply removes the
sequencer state without touching the worktree, index or HEAD. We
decided that this would be a nice low-level command to implement
(since I find myself doing `rm -rf .git/rebase-todo` sometimes).
Sure, "abort" and a lot of other porcelain would be nice- we can
always implement them carefully later :)
Thanks.
-- Ram
^ permalink raw reply
* Re: input director not compatible with git right-click
From: Sitaram Chamarty @ 2011-11-15 16:09 UTC (permalink / raw)
To: Carlos Martín Nieto, Eric, git
In-Reply-To: <20111114144024.GD10025@beez.lab.cmartin.tk>
On Mon, Nov 14, 2011 at 8:10 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Sun, Nov 13, 2011 at 04:34:26PM +0000, Eric wrote:
>> Hi,
>>
>> New in Git use, I use it do dev on window some administrative script. I use as
>> well Input director to share keyboard and mouse on multiple computer.
>
> Do you mean you're using it on the Windows OS?
>
>>
>> when I right-clicked on an item, it works when input director is disabled. If
>
> Right-click on what? git doesn't have a graphical interface. If you're
> using a graphical front-end to git, you should send them a bug report.
git comes with 3 perfectly cromulent graphical programs, and one of
them is indispensable.
The real reason the original question is not meaningful here is that
-- if he hadn't mentioned "share keyboard and mouse on multiple
computer" most people would have no clue what the heck it was, and
obscure software does... obscure things, so it should be reported to
them. not here.
--
Sitaram
^ permalink raw reply
* Re: [PATCH 0/7] New sequencer workflow!
From: Phil Hord @ 2011-11-15 15:46 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Junio C Hamano, Jonathan Nieder, Christian Couder
In-Reply-To: <1321181181-23923-1-git-send-email-artagnon@gmail.com>
On Sun, Nov 13, 2011 at 5:46 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> $ git revert moo..baz
> ... conflict ...
> $ echo "resolved" >problematicfile
> $ git add problematicfile
> $ git sequencer --continue
>
> In other words, it just doesn't matter how you started what sequencing
> operation: you can always continue a it with "git sequencer
> --continue" and reset it with "git sequencer --reset".
I see that --reset was added to cherry-pick, revert and sequencer
around the same time back in August. Shouldn't it be spelled
"--abort" instead?
This would align better with other commands that do the same thing
(am, merge, notes-merge, rebase) since they all appear to spell it
"--abort". Also, it will make it easier in git 2.x when we begin
using "git continue" and "git abort" rather than "git reset".
Phil
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Shawn Pearce @ 2011-11-15 15:03 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <CACf55T6BGds_D=nbb8G=m+Jwr+bHFruCs-Q0+FOO+WXitXEJ-g@mail.gmail.com>
On Tue, Nov 15, 2011 at 05:52, Dmitry Smirnov <divis1969@gmail.com> wrote:
> I have problems with downloading Android code from android.googlesource.com.
>
> The error says: fatal: branch stable is not signed
>
> I was trying to figure out what happens and finally came to conclusion
> that this is a problem of the git.
Not likely. This is an error printed by the "repo" tool used by
Android. It typically indicates the repo command you are executing is
pointing to a URL that may be a local mirror and contain additional
patches in it that were not signed by me.
I would suggest starting over by downloading repo per [1] and using
that script to start the process.
[1] http://source.android.com/source/downloading.html
> When I try to clone the git itself using https
> (https://git.kernel.org/pub/scm/git/git.git) I'm getting the follwing
> error:
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> If I use the http URL (http://git.kernel.org/pub/scm/git/git.git) I
> can clone with no problems.
This may be a problem with the git.kernel.org HTTP server. It is
probably not a problem with Git itself.
^ permalink raw reply
* Re: [PATCH] git-show-ref: fix escaping in asciidoc source
From: Michael Haggerty @ 2011-11-15 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1319050336-24717-1-git-send-email-mhagger@alum.mit.edu>
Junio,
Did this one fall through the cracks? I don't see it in your tree.
Michael
On 10/19/2011 08:52 PM, mhagger@alum.mit.edu wrote:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
> One of the "^" characters was not coming through in the man page.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> Documentation/git-show-ref.txt | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
> index 3c45895..87f358d 100644
> --- a/Documentation/git-show-ref.txt
> +++ b/Documentation/git-show-ref.txt
> @@ -44,7 +44,7 @@ OPTIONS
> -d::
> --dereference::
>
> - Dereference tags into object IDs as well. They will be shown with "^{}"
> + Dereference tags into object IDs as well. They will be shown with "{caret}\{\}"
> appended.
>
> -s::
> @@ -75,7 +75,7 @@ OPTIONS
> Make 'git show-ref' act as a filter that reads refs from stdin of the
> form "^(?:<anything>\s)?<refname>(?:{backslash}{caret}\{\})?$"
> and performs the following actions on each:
> - (1) strip "^{}" at the end of line if any;
> + (1) strip "{caret}\{\}" at the end of line if any;
> (2) ignore if pattern is provided and does not head-match refname;
> (3) warn if refname is not a well-formed refname and skip;
> (4) ignore if refname is a ref that exists in the local repository;
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Git 1.7.5 problem with HTTPS
From: Dmitry Smirnov @ 2011-11-15 13:52 UTC (permalink / raw)
To: git
Hi,
I have problems with downloading Android code from android.googlesource.com.
The error says: fatal: branch stable is not signed
I was trying to figure out what happens and finally came to conclusion
that this is a problem of the git.
When I try to clone the git itself using https
(https://git.kernel.org/pub/scm/git/git.git) I'm getting the follwing
error:
warning: remote HEAD refers to nonexistent ref, unable to checkout.
If I use the http URL (http://git.kernel.org/pub/scm/git/git.git) I
can clone with no problems.
I was also considering that the problem is caused by proxy. But when I
tried to clone the same git source from another host via the same
proxy, it works pretty good. The difference is the git version: on the
first host it is 1.7.5.4 (comes with Ubuntu 11.10), on the second -
1.7.0.4
I was trying to collect some tcpdump and it shows the follwoing sequence
15 1.962132 X.X.X.X Y.Y.Y.Y HTTP 204 CONNECT git.kernel.org:443 HTTP/1.1
17 3.687364 Y.Y.Y.Y X.X.X.X HTTP 105 HTTP/1.0 200 Connection established
19 3.764793 X.X.X.X Y.Y.Y.Y TLSv1 208 Client Hello
21 3.815135 X.X.X.X Y.Y.Y.Y TLSv1 215 Ignored Unknown Record
23 4.045326 Y.Y.Y.Y X.X.X.X TLSv1 2239 Server Hello, Certificate,
Server Key Exchange, Server Hello Done
25 4.055059 Y.Y.Y.Y X.X.X.X TLSv1 73 Alert (Level: Fatal, Description:
Protocol Version)
As you can see, session seems terminated with fatal alert. It looks
like client tries to use TLS 1.2 but server accepts only TLS 1.0. But
this is just assumption.
Also, it is no clear what is that Ignored Unknown Record. But it
contains uncripted text: GET
/pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.5.4 Host: git.kernel.org Accept: */* Pragma:
no-cache
So, any suggesstions?
Dmitry
^ permalink raw reply
* Re: [PATCH] Add built-in diff patterns for MATLAB code
From: Thomas Rast @ 2011-11-15 13:14 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Git List, Junio C Hamano
In-Reply-To: <df238a1919b7c7d05749b4aa637fe2c7@isy.liu.se>
Gustaf Hendeby wrote:
> On Tue, 15 Nov 2011 13:37:06 +0100, Thomas Rast wrote:
> > Gustaf Hendeby wrote:
> >> +PATTERNS("matlab",
> >> +
> >> "^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
> >> + "[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+|[=~<>]=|\\|\\||&&"),
> >
> > Shouldn't you, for matlab, ensure that ./ "sticks" as a single word
> > since it is an operator? At least we used the same logic for the C
> > ||
> > and && operators, which you copied.
>
> Good point Thomas, I forgot all about the .-operators. I will add
> \.[*/^'] as words, are there any other ones to consider? Thanks for
> paying attention!
Uh, I'm afraid it's been years since I did matlab. But
http://www.mathworks.ch/help/techdoc/matlab_prog/f0-40063.html
seems to indicate you forgot '.\'.
Please also update the testcases to whether this splits correctly,
e.g., by changing './' to '/'.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Add built-in diff patterns for MATLAB code
From: Gustaf Hendeby @ 2011-11-15 12:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List, Junio C Hamano
In-Reply-To: <201111151337.07013.trast@student.ethz.ch>
On Tue, 15 Nov 2011 13:37:06 +0100, Thomas Rast wrote:
> Gustaf Hendeby wrote:
>> +PATTERNS("matlab",
>> +
>> "^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
>> + "[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+|[=~<>]=|\\|\\||&&"),
>
> Shouldn't you, for matlab, ensure that ./ "sticks" as a single word
> since it is an operator? At least we used the same logic for the C
> ||
> and && operators, which you copied.
Good point Thomas, I forgot all about the .-operators. I will add
\.[*/^'] as words, are there any other ones to consider? Thanks for
paying attention!
/Gustaf
^ permalink raw reply
* Re: [PATCH] Add built-in diff patterns for MATLAB code
From: Thomas Rast @ 2011-11-15 12:37 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Git List, Junio C Hamano
In-Reply-To: <1321191764-11972-1-git-send-email-hendeby@isy.liu.se>
Gustaf Hendeby wrote:
> +PATTERNS("matlab",
> + "^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
> + "[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+|[=~<>]=|\\|\\||&&"),
Shouldn't you, for matlab, ensure that ./ "sticks" as a single word
since it is an operator? At least we used the same logic for the C ||
and && operators, which you copied.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Thomas Rast @ 2011-11-15 12:11 UTC (permalink / raw)
To: Jeff King, Franck Bui-Huu; +Cc: Erik Faye-Lund, git, gitster, j6t, rene.scharfe
In-Reply-To: <20111115102807.GA18649@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Nov 15, 2011 at 11:22:48AM +0100, Thomas Rast wrote:
> >
> > I see valgrind failures bisecting to this commit, like so:
> >
> > ==19125== Syscall param execve(argv[i]) points to unaddressable byte(s)
> > ==19125== at 0x5303CB7: execve (in /lib64/libc-2.11.3.so)
> > ==19125== by 0x53045A5: execvpe (in /lib64/libc-2.11.3.so)
> > ==19125== by 0x4B183C: execv_git_cmd (exec_cmd.c:137)
> > ==19125== by 0x4F305E: start_command (run-command.c:277)
> > ==19125== by 0x47F5C9: cmd_upload_archive (upload-archive.c:98)
> > ==19125== by 0x4051F4: run_builtin (git.c:308)
> > ==19125== by 0x40538F: handle_internal_command (git.c:466)
> > ==19125== by 0x405556: main (git.c:553)
> > ==19125== Address 0x7feffe7d0 is not stack'd, malloc'd or (recently) free'd
> >
> > when running 'make valgrind' in current master. Let me know if you
> > need more information.
>
> With which test, and on what OS? I couldn't replicate running
> t5000 on Linux.
11, and many others after it, on a pretty vanilla opensuse 11.4 VM I
use almost exclusively for the valgrind runs. I used a pre-3.7 SVN
valgrind build, but 3.6.1 (shipped with opensuse) finds the same.
But after a closer look I think this patch just prodded it enough to
unearth long-existing undefined behaviour: prepare_argv() summarizes
to something like
static void prepare_argv(const char **sent_argv, const char **argv)
{
char *p, buf[4096];
for (p = buf;;) {
len = packet_read_line(0, p, (buf + sizeof buf) - p);
/* ... p always points into buf ... */
sent_argv[sent_argc++] = p;
p += len;
*p++ = 0;
}
sent_argv[sent_argc] = NULL;
}
The code appears to have looked like this ever since the addition of
that file back in 39345a2 (Add git-upload-archive, 2006-09-07). So
the elements of sent_argv have apparently always pointed into the
stack-allocated 'buf'.
(This correlates with the "Address 0x7feffe7d0 is not stack'd", even
though it's pretty clearly an address into the stack.)
A quick band-aid would be to heap-allocate it instead:
diff --git i/builtin/upload-archive.c w/builtin/upload-archive.c
index c57e8bd..6ab50d3 100644
--- i/builtin/upload-archive.c
+++ w/builtin/upload-archive.c
@@ -22,9 +22,10 @@ static const char lostchild[] =
static void prepare_argv(const char **sent_argv, const char **argv)
{
const char *arg_cmd = "argument ";
- char *p, buf[4096];
+ char *p, *buf;
int sent_argc;
int len;
+ buf = xmalloc(4096);
/* put received options in sent_argv[] */
sent_argc = 2;
@@ -32,7 +33,7 @@ static void prepare_argv(const char **sent_argv, const char **argv)
sent_argv[1] = "--remote-request";
for (p = buf;;) {
/* This will die if not enough free space in buf */
- len = packet_read_line(0, p, (buf + sizeof buf) - p);
+ len = packet_read_line(0, p, (buf + 4096) - p);
if (len == 0)
break; /* got a flush */
if (sent_argc > MAX_ARGS - 2)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Git, Parrot, Perl6, Rakudo for G4 MAC
From: Greg @ 2011-11-15 10:36 UTC (permalink / raw)
To: git
Howdy:
Could someone please assist me in locating the resources to "GIT"
this stuff going on a G4 MAC PPC? I
keep getting weird bugs.
Need me to be more explicit? Ok - it says gcc v3.3 isn't compatible, and a
bunch of other sheet!
I'd like to start messing with this while I'm waiting for my Debian
Linux box to be returned. (A friend
borrowed it to do some work:
He installed a horribly virulent bug called WInBlows XP!!!!)
I already have Perl5.10.1 working fine, and performing
numerous marvelous tasks, so I (perhaps
mistakenly) thought it would be an easy addition.
Cheers,
Greg
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Jeff King @ 2011-11-15 10:28 UTC (permalink / raw)
To: Thomas Rast; +Cc: Erik Faye-Lund, git, gitster, j6t, rene.scharfe
In-Reply-To: <201111151122.48378.trast@student.ethz.ch>
On Tue, Nov 15, 2011 at 11:22:48AM +0100, Thomas Rast wrote:
> > Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
> > now works.
>
> I see valgrind failures bisecting to this commit, like so:
>
> ==19125== Syscall param execve(argv[i]) points to unaddressable byte(s)
> ==19125== at 0x5303CB7: execve (in /lib64/libc-2.11.3.so)
> ==19125== by 0x53045A5: execvpe (in /lib64/libc-2.11.3.so)
> ==19125== by 0x4B183C: execv_git_cmd (exec_cmd.c:137)
> ==19125== by 0x4F305E: start_command (run-command.c:277)
> ==19125== by 0x47F5C9: cmd_upload_archive (upload-archive.c:98)
> ==19125== by 0x4051F4: run_builtin (git.c:308)
> ==19125== by 0x40538F: handle_internal_command (git.c:466)
> ==19125== by 0x405556: main (git.c:553)
> ==19125== Address 0x7feffe7d0 is not stack'd, malloc'd or (recently) free'd
>
> when running 'make valgrind' in current master. Let me know if you
> need more information.
With which test, and on what OS? I couldn't replicate running
t5000 on Linux.
-Peff
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Thomas Rast @ 2011-11-15 10:22 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, gitster, j6t, peff, rene.scharfe
In-Reply-To: <1319472131-3968-4-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund wrote:
> The POSIX-function fork is not supported on Windows. Use our
> start_command API instead.
>
> As this is the last call-site that depends on the fork-stub in
> compat/mingw.h, remove that as well.
>
> Add an undocumented flag to git-archive that tells it that the
> action originated from a remote, so features can be disabled.
> Thanks to Jeff King for work on this part.
>
> Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
> now works.
I see valgrind failures bisecting to this commit, like so:
==19125== Syscall param execve(argv[i]) points to unaddressable byte(s)
==19125== at 0x5303CB7: execve (in /lib64/libc-2.11.3.so)
==19125== by 0x53045A5: execvpe (in /lib64/libc-2.11.3.so)
==19125== by 0x4B183C: execv_git_cmd (exec_cmd.c:137)
==19125== by 0x4F305E: start_command (run-command.c:277)
==19125== by 0x47F5C9: cmd_upload_archive (upload-archive.c:98)
==19125== by 0x4051F4: run_builtin (git.c:308)
==19125== by 0x40538F: handle_internal_command (git.c:466)
==19125== by 0x405556: main (git.c:553)
==19125== Address 0x7feffe7d0 is not stack'd, malloc'd or (recently) free'd
when running 'make valgrind' in current master. Let me know if you
need more information.
--
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