* Re: [PATCH 1/3] get_sha1_oneline: do not leak or double free
From: Junio C Hamano @ 2010-12-13 6:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jonathan Niedier, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski, Thiago Farina
In-Reply-To: <1292209275-17451-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Double free can happen when commit->buffer == NULL in the first
> iteration, then != NULL in the next two iterations.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> sha1_name.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Thanks. First the later hunk:
> diff --git a/sha1_name.c b/sha1_name.c
> index 2c3a5fb..13ee6f5 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -740,6 +740,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> free_commit_list(list);
> for (l = backup; l; l = l->next)
> clear_commit_marks(l->item, ONELINE_SEEN);
> + free_commit_list(backup);
> return retval;
> }
This is necessary, but is unrelated to the topic, no?
> @@ -718,13 +718,13 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> commit = pop_most_recent_commit(&list, ONELINE_SEEN);
> if (!parse_object(commit->object.sha1))
> continue;
> - free(temp_commit_buffer);
> if (commit->buffer)
> p = commit->buffer;
> else {
> p = read_sha1_file(commit->object.sha1, &type, &size);
> if (!p)
> continue;
> + free(temp_commit_buffer);
> temp_commit_buffer = p;
> }
> if (!(p = strstr(p, "\n\n")))
This looks very convoluted.
I think the "temp-commit-buffer with a lifetime one iteration more than
the loop body itself" is merely a misguided attempt to avoid sprinkling
many free() calls inside the loop that has irregular exit points with
continue and break.
If you rewrite the loop to have more regular structure, there is no reason
to have such a temporary variable with tricky lifespan.
I think the following is easier to read and conveys what the code is
trying to do more clearly. No?
sha1_name.c | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 2c3a5fb..2cc7a42 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -693,8 +693,7 @@ static int handle_one_ref(const char *path,
static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
{
struct commit_list *list = NULL, *backup = NULL, *l;
- int retval = -1;
- char *temp_commit_buffer = NULL;
+ int found = 0;
regex_t regex;
if (prefix[0] == '!') {
@@ -710,37 +709,40 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
for (l = list; l; l = l->next)
commit_list_insert(l->item, &backup);
while (list) {
- char *p;
+ char *p, *to_free = NULL;
struct commit *commit;
enum object_type type;
unsigned long size;
+ int matches;
commit = pop_most_recent_commit(&list, ONELINE_SEEN);
if (!parse_object(commit->object.sha1))
continue;
- free(temp_commit_buffer);
if (commit->buffer)
p = commit->buffer;
else {
p = read_sha1_file(commit->object.sha1, &type, &size);
if (!p)
continue;
- temp_commit_buffer = p;
+ to_free = p;
}
- if (!(p = strstr(p, "\n\n")))
- continue;
- if (!regexec(®ex, p + 2, 0, NULL, 0)) {
+
+ p = strstr(p, "\n\n");
+ matches = p && !regexec(®ex, p + 2, 0, NULL, 0);
+ free(to_free);
+
+ if (matches) {
hashcpy(sha1, commit->object.sha1);
- retval = 0;
+ found = 1;
break;
}
}
regfree(®ex);
- free(temp_commit_buffer);
free_commit_list(list);
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
- return retval;
+ free_commit_list(backup);
+ return found ? 0 : -1;
}
struct grab_nth_branch_switch_cbdata {
^ permalink raw reply related
* Re: [PATCH 3/3] get_sha1: support ref^{/regex} syntax
From: Jonathan Nieder @ 2010-12-13 4:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: git, Junio C Hamano, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski, Thiago Farina
In-Reply-To: <AANLkTik2M=PPCXqtepRhntVYofrA0PUgzBLvdMNeeP5P@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> 2010/12/13 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>> This works like :/ syntax, but only limited to one ref.
>
> Argh.. I read Jonthan's comment too late. Maybe "limited to one commit
> tip (of a DAG)"?
As long as it doesn't filter into the documentation, I don't really
mind. :)
^ permalink raw reply
* Re: [PATCH] git_getpass: fix ssh-askpass behaviour
From: Xin Wang @ 2010-12-13 4:09 UTC (permalink / raw)
To: git
Junio C Hamano <gitster <at> pobox.com> writes:
>
> Alexander Sulfrian <alexander <at> sulfrian.net> writes:
>
> > call ssh-askpass only if the display environment variable is also set
> > ---
>
> I do not use it at all so I don't know for sure, but doesn't this break
> OSX?
>
> 20f3490 (web--browse: fix Mac OS X GUI detection for 10.6, 2009-09-14)
>
> is an example that you can be fully graphical without having DISPLAY set
> in some environment. MinGW folks may want to chime in as well.
>
How about test whether git is associated with a terminal or not?
> > connect.c | 7 +++++--
> > 1 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/connect.c b/connect.c
> > index 57dc20c..2810e3b 100644
> > --- a/connect.c
> > +++ b/connect.c
> > @@ -621,7 +621,7 @@ int finish_connect(struct child_process *conn)
> >
> > char *git_getpass(const char *prompt)
> > {
> > - const char *askpass;
> > + const char *askpass, *display;
> > struct child_process pass;
> > const char *args[3];
> > static struct strbuf buffer = STRBUF_INIT;
> > @@ -631,7 +631,10 @@ char *git_getpass(const char *prompt)
> > askpass = askpass_program;
> > if (!askpass)
> > askpass = getenv("SSH_ASKPASS");
> > - if (!askpass || !(*askpass)) {
> > +
> > + /* only call askpass if display is set */
> > + display = getenv("DISPLAY");
> > + if (!display || !(*display) || !askpass || !(*askpass))
> > char *result = getpass(prompt);
> > if (!result)
> > die_errno("Could not read password");
>
>
Xin Wang
^ permalink raw reply
* Re: developing a modified Linux-style workflow
From: Hans-Christoph Steiner @ 2010-12-13 3:23 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <20101213033145.GA3609@gmail.com>
On Dec 12, 2010, at 10:31 PM, David Aguilar wrote:
> On Sun, Dec 12, 2010 at 05:24:16PM -0500, Hans-Christoph Steiner
> wrote:
>>
>> Hey all,
>>
>> (and my second post on this list...)
>>
>> I've gotten pretty good at git, and its helping me already with
>> managing the very odd workflows I have with the software I work a
>> lot on called Pd (http://puredata.info). My role in Pd development
>> is like a Linux lieutenant.
>>
>> I also the main dev for an app called Pd-extended, which is based on
>> Pd. Now I'm stuck trying to figure out how to use git to match my
>> current workflow for Pd-extended, which is a kind of long-lived
>> branch, almost like a friendly fork. So its kind of close to the
>> Linux workflow with me as a lieutenant, but not quite.
>>
>> What makes it tricky is that I make releases directly from my repo
>> that are widely used. So my repo is both lieutenant and dictator at
>> the same time. So that's where I am stumped. I want to be able to
>> rebase and push to a public repo, but that would be stupid. So
>> there has got to be another way.
>
> Have you considered periodically merging Pd into Pd-extended
> as an alternative to rebasing? It might even be easier to
> manage in the long-term.
The thing I really like about the lieutenant workflow is that I can
keep my patches at the top of history, and it automatically handles it
once my patch is handled upstream. It seems that merging Pd into Pd-
extended would leave me with a very complicated history.
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
^ permalink raw reply
* Re: developing a modified Linux-style workflow
From: David Aguilar @ 2010-12-13 3:31 UTC (permalink / raw)
To: Hans-Christoph Steiner; +Cc: git
In-Reply-To: <7EAE16CF-A9A8-47A6-9294-3646CCDB0E9C@at.or.at>
On Sun, Dec 12, 2010 at 05:24:16PM -0500, Hans-Christoph Steiner wrote:
>
> Hey all,
>
> (and my second post on this list...)
>
> I've gotten pretty good at git, and its helping me already with
> managing the very odd workflows I have with the software I work a
> lot on called Pd (http://puredata.info). My role in Pd development
> is like a Linux lieutenant.
>
> I also the main dev for an app called Pd-extended, which is based on
> Pd. Now I'm stuck trying to figure out how to use git to match my
> current workflow for Pd-extended, which is a kind of long-lived
> branch, almost like a friendly fork. So its kind of close to the
> Linux workflow with me as a lieutenant, but not quite.
>
> What makes it tricky is that I make releases directly from my repo
> that are widely used. So my repo is both lieutenant and dictator at
> the same time. So that's where I am stumped. I want to be able to
> rebase and push to a public repo, but that would be stupid. So
> there has got to be another way.
Have you considered periodically merging Pd into Pd-extended
as an alternative to rebasing? It might even be easier to
manage in the long-term.
--
David
^ permalink raw reply
* Re: Please pull gitk.git master branch
From: Junio C Hamano @ 2010-12-13 3:11 UTC (permalink / raw)
To: Paul Mackerras, Alexandre Erwin Ittner; +Cc: git
In-Reply-To: <7vwrne8tow.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thanks, pulled (not yet pushed out).
Yikes.
Paul, has this ever been install-tested before you accepted the "pt-BR"
patch to your repository?
"msgfmt --tcl" produces po/pt_br.msg for me, but the Makefile wants to
install po/pt_BR.msg and fails. Perhaps the poor-man's po2msg.sh does not
have this glitch and produces po/pt_BR.msg, but I don't think that is an
excuse for not checking with both that script and the real msgfmt before
the change gets this far.
Using the -o option on the msgfmt command line to force the command to
generate pt_BR.msg fails with:
msgfmt: --tcl and --output-file are mutually exclusive
Combined with this and the fact that msgfmt produces po/pt_br.msg out of
the input po/pt_BR.po makes me suspect that Tcl runtime enviornment does
not actually expect pt_BR.msg but want to see the country part downcased.
In which case we may need to fix po2msg.sh to match that behaviour.
An workaround would be to rename po/pt_BR.po to po/pt_br.po but I don't
know if there are unexpected side effects if we did that.
I'd like to see this glitch sorted out before I push out the result of the
merge, so it is likely there won't be a pushout tonight. We need to know:
* Is this "downcase the country part for --tcl" a bug in the particular
version of msgfmt I happen to have (it is 0.17 from GNU gettext on
Debian), or is it the filename convention expected by the Tcl i18n
runtime environment to have both language and country in lowercase?
* What is the recommended best practice in Tcl i18n community for naming
lang_COUNTRY.po file? Do people typically spell the COUNTRY in
uppercase and let "msgfmt --tcl" downcase, and deal with the filename
case issues in the Makefile themselves? This feels yucky, as it means
that we cannot use '%.msg : %.po' dependency pattern, but need to list
the dependencies by hand. Or do they spell country part in lowercase
to avoid this whole issue?
My _preferred_ outcome is to see that naming the input "po/pt_br.po" and
using the output "po/pt_br.msg" is the BCP, but I'd like somebody to find
out what the accepted practice would be in the Tcl land first.
^ permalink raw reply
* Re: [PATCH 3/3] get_sha1: support ref^{/regex} syntax
From: Nguyen Thai Ngoc Duy @ 2010-12-13 3:10 UTC (permalink / raw)
To: git, Junio C Hamano, Jonathan Niedier
Cc: Kevin Ballard, Yann Dirson, Jeff King, Jakub Narebski,
Thiago Farina, Nguyễn Thái Ngọc Duy
In-Reply-To: <1292209275-17451-3-git-send-email-pclouds@gmail.com>
2010/12/13 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> This works like :/ syntax, but only limited to one ref.
Argh.. I read Jonthan's comment too late. Maybe "limited to one commit
tip (of a DAG)"?
--
Duy
^ permalink raw reply
* [PATCH 3/3] get_sha1: support ref^{/regex} syntax
From: Nguyễn Thái Ngọc Duy @ 2010-12-13 3:01 UTC (permalink / raw)
To: git, Junio C Hamano, Jonathan Niedier
Cc: Kevin Ballard, Yann Dirson, Jeff King, Jakub Narebski,
Thiago Farina, Nguyễn Thái Ngọc Duy
In-Reply-To: <1292209275-17451-1-git-send-email-pclouds@gmail.com>
This works like :/ syntax, but only limited to one ref.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/revisions.txt | 6 +++
sha1_name.c | 34 +++++++++++++------
t/t1511-rev-parse-caret.sh | 73 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 102 insertions(+), 11 deletions(-)
create mode 100755 t/t1511-rev-parse-caret.sh
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 3d4b79c..174fa8e 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -106,6 +106,12 @@ the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.
and dereference the tag recursively until a non-tag object is
found.
+* A suffix '{caret}' to a revision parameter followed by a brace
+ pair that contains a text led by a slash (e.g. `HEAD^{/fix nasty bug}`):
+ this is the same as `:/fix nasty bug` syntax below except that
+ it returns the youngest matching commit which is reachable from
+ the ref before '{caret}'.
+
* A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names
a commit whose commit message matches the specified regular expression.
This name returns the youngest matching commit which is
diff --git a/sha1_name.c b/sha1_name.c
index 3c2c61c..a7e1bcb 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -529,6 +529,7 @@ struct object *peel_to_type(const char *name, int namelen,
}
}
+static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);
static int peel_onion(const char *name, int len, unsigned char *sha1)
{
unsigned char outer[20];
@@ -564,6 +565,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
expected_type = OBJ_BLOB;
else if (sp[0] == '}')
expected_type = OBJ_NONE;
+ else if (sp[0] == '/')
+ expected_type = OBJ_COMMIT;
else
return -1;
@@ -578,19 +581,28 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
if (!o || (!o->parsed && !parse_object(o->sha1)))
return -1;
hashcpy(sha1, o->sha1);
+ return 0;
}
- else {
- /*
- * At this point, the syntax look correct, so
- * if we do not get the needed object, we should
- * barf.
- */
- o = peel_to_type(name, len, o, expected_type);
- if (o) {
- hashcpy(sha1, o->sha1);
- return 0;
- }
+
+ /*
+ * At this point, the syntax look correct, so if we do not get
+ * the needed object, we should barf.
+ */
+ o = peel_to_type(name, len, o, expected_type);
+ if (!o)
return -1;
+
+ hashcpy(sha1, o->sha1);
+ if (sp[0] == '/') { /* ^{/foo} */
+ struct commit_list *list = NULL;
+ char *prefix;
+ int ret;
+
+ commit_list_insert((struct commit *)o, &list);
+ prefix = xstrndup(sp + 1, name + len - 1 - (sp + 1));
+ ret = get_sha1_oneline(prefix, sha1, list);
+ free(prefix);
+ return ret;
}
return 0;
}
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
new file mode 100755
index 0000000..5c8439c
--- /dev/null
+++ b/t/t1511-rev-parse-caret.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+test_description='tests for ref^{stuff}'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo blob >a-blob &&
+ git tag -a -m blob blob-tag `git hash-object -w a-blob`
+ mkdir a-tree &&
+ echo moreblobs >a-tree/another-blob &&
+ git add . &&
+ TREE_SHA1=`git write-tree` &&
+ git tag -a -m tree tree-tag "$TREE_SHA1" &&
+ git commit -m Initial &&
+ git tag -a -m commit commit-tag &&
+ git branch ref &&
+ git checkout master &&
+ echo modified >>a-blob &&
+ git add -u &&
+ git commit -m Modified
+'
+
+test_expect_success 'ref^{non-existent}' '
+ test_must_fail git rev-parse ref^{non-existent}
+'
+
+test_expect_success 'ref^{}' '
+ git rev-parse ref >expected &&
+ git rev-parse ref^{} >actual &&
+ test_cmp expected actual &&
+ git rev-parse commit-tag^{} >actual &&
+ test_cmp expected actual
+'
+
+test_expect_success 'ref^{commit}' '
+ git rev-parse ref >expected &&
+ git rev-parse ref^{commit} >actual &&
+ test_cmp expected actual &&
+ git rev-parse commit-tag^{commit} >actual &&
+ test_cmp expected actual &&
+ test_must_fail git rev-parse tree-tag^{commit} &&
+ test_must_fail git rev-parse blob-tag^{commit}
+'
+
+test_expect_success 'ref^{tree}' '
+ echo $TREE_SHA1 >expected &&
+ git rev-parse ref^{tree} >actual &&
+ test_cmp expected actual &&
+ git rev-parse commit-tag^{tree} >actual &&
+ test_cmp expected actual &&
+ git rev-parse tree-tag^{tree} >actual &&
+ test_cmp expected actual &&
+ test_must_fail git rev-parse blob-tag^{tree}
+'
+
+test_expect_success 'ref^{/}' '
+ git rev-parse master >expected &&
+ git rev-parse master^{/} >actual &&
+ test_cmp expected actual
+'
+
+test_expect_success 'ref^{/non-existent}' '
+ test_must_fail git rev-parse master^{/non-existent}
+'
+
+test_expect_success 'ref^{/Initial}' '
+ git rev-parse ref >expected &&
+ git rev-parse master^{/Initial} >actual &&
+ test_cmp expected actual
+'
+
+test_done
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* [PATCH 2/3] get_sha1_oneline: let callers initialize the commit tips for traverse
From: Nguyễn Thái Ngọc Duy @ 2010-12-13 3:01 UTC (permalink / raw)
To: git, Junio C Hamano, Jonathan Niedier
Cc: Kevin Ballard, Yann Dirson, Jeff King, Jakub Narebski,
Thiago Farina, Nguyễn Thái Ngọc Duy
In-Reply-To: <1292209275-17451-1-git-send-email-pclouds@gmail.com>
This gives callers more control, i.e. which ref will be searched from.
get_sha1_oneline takes care of ONELINE_SEEN marks (which is now TMP_MARK)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
sha1_name.c | 62 +++++++++++++++++++++++++++++++---------------------------
1 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 13ee6f5..3c2c61c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -6,6 +6,8 @@
#include "tree-walk.h"
#include "refs.h"
#include "remote.h"
+#include "diff.h"
+#include "revision.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -669,30 +671,10 @@ static int get_sha1_1(const char *name, int len, unsigned char *sha1)
* For future extension, ':/!' is reserved. If you want to match a message
* beginning with a '!', you have to repeat the exclamation mark.
*/
-#define ONELINE_SEEN (1u<<20)
-
-static int handle_one_ref(const char *path,
- const unsigned char *sha1, int flag, void *cb_data)
-{
- struct commit_list **list = cb_data;
- struct object *object = parse_object(sha1);
- if (!object)
- return 0;
- if (object->type == OBJ_TAG) {
- object = deref_tag(object, path, strlen(path));
- if (!object)
- return 0;
- }
- if (object->type != OBJ_COMMIT)
- return 0;
- insert_by_date((struct commit *)object, list);
- object->flags |= ONELINE_SEEN;
- return 0;
-}
-
-static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
+static int get_sha1_oneline(const char *prefix, unsigned char *sha1,
+ struct commit_list *list)
{
- struct commit_list *list = NULL, *backup = NULL, *l;
+ struct commit_list *backup = NULL, *l;
int retval = -1;
char *temp_commit_buffer = NULL;
regex_t regex;
@@ -706,16 +688,17 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
if (regcomp(®ex, prefix, REG_EXTENDED))
die("Invalid search pattern: %s", prefix);
- for_each_ref(handle_one_ref, &list);
- for (l = list; l; l = l->next)
+ for (l = list; l; l = l->next) {
+ l->item->object.flags |= TMP_MARK;
commit_list_insert(l->item, &backup);
+ }
while (list) {
char *p;
struct commit *commit;
enum object_type type;
unsigned long size;
- commit = pop_most_recent_commit(&list, ONELINE_SEEN);
+ commit = pop_most_recent_commit(&list, TMP_MARK);
if (!parse_object(commit->object.sha1))
continue;
if (commit->buffer)
@@ -739,7 +722,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
free(temp_commit_buffer);
free_commit_list(list);
for (l = backup; l; l = l->next)
- clear_commit_marks(l->item, ONELINE_SEEN);
+ clear_commit_marks(l->item, TMP_MARK);
free_commit_list(backup);
return retval;
}
@@ -1067,6 +1050,24 @@ int get_sha1_with_mode_1(const char *name, unsigned char *sha1, unsigned *mode,
return ret;
}
+static int handle_one_ref(const char *path,
+ const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct commit_list **list = cb_data;
+ struct object *object = parse_object(sha1);
+ if (!object)
+ return 0;
+ if (object->type == OBJ_TAG) {
+ object = deref_tag(object, path, strlen(path));
+ if (!object)
+ return 0;
+ }
+ if (object->type != OBJ_COMMIT)
+ return 0;
+ insert_by_date((struct commit *)object, list);
+ return 0;
+}
+
int get_sha1_with_context_1(const char *name, unsigned char *sha1,
struct object_context *oc,
int gently, const char *prefix)
@@ -1089,9 +1090,12 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,
int stage = 0;
struct cache_entry *ce;
int pos;
- if (namelen > 2 && name[1] == '/')
+ if (namelen > 2 && name[1] == '/') {
+ struct commit_list *list = NULL;
+ for_each_ref(handle_one_ref, &list);
/* don't need mode for commit */
- return get_sha1_oneline(name + 2, sha1);
+ return get_sha1_oneline(name + 2, sha1, list);
+ }
if (namelen < 3 ||
name[2] != ':' ||
name[1] < '0' || '3' < name[1])
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* [PATCH 1/3] get_sha1_oneline: do not leak or double free
From: Nguyễn Thái Ngọc Duy @ 2010-12-13 3:01 UTC (permalink / raw)
To: git, Junio C Hamano, Jonathan Niedier
Cc: Kevin Ballard, Yann Dirson, Jeff King, Jakub Narebski,
Thiago Farina, Nguyễn Thái Ngọc Duy
Double free can happen when commit->buffer == NULL in the first
iteration, then != NULL in the next two iterations.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
sha1_name.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 2c3a5fb..13ee6f5 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -718,13 +718,13 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
commit = pop_most_recent_commit(&list, ONELINE_SEEN);
if (!parse_object(commit->object.sha1))
continue;
- free(temp_commit_buffer);
if (commit->buffer)
p = commit->buffer;
else {
p = read_sha1_file(commit->object.sha1, &type, &size);
if (!p)
continue;
+ free(temp_commit_buffer);
temp_commit_buffer = p;
}
if (!(p = strstr(p, "\n\n")))
@@ -740,6 +740,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
free_commit_list(list);
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
+ free_commit_list(backup);
return retval;
}
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* Re: [RFC PATCH 0/2] gitweb: die_error (error handling) improvements
From: J.H. @ 2010-12-13 2:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20101213004259.9475.87376.stgit@localhost.localdomain>
On 12/12/2010 04:46 PM, Jakub Narebski wrote:
> The following two patch series changes improve error / exception
> handling in gitweb, preparing the way for gitweb output caching, but
> useful even without it.
>
> I'm sending this patch series early to gather feedback on possible
> ways of improving error / exception handling in gitweb.
Personally, instead of another band-aid over this problem, and adding
(or further legitimizing) goto statements inside gitweb I'd much *MUCH*
rather we actually put in the work to actually clean this up.
This is the direction I'm heading in, which I mentioned in an earlier
e-mail.
There are a *LOT* of disadvantages to the eval mechanism in perl. It's
the standard but gitweb is getting more and more complex, and eval is
simplistic. Couple that with the complexity and uncertainty that things
like goto add to the code, I would *MUCH* rather not see this series go
in, as I think it is the wrong approach to fixing this.
- John 'Warthog9' Hawley
^ permalink raw reply
* RE: Git SVN non-standard branch/tag/trunk layout
From: Albert Krawczyk @ 2010-12-13 0:55 UTC (permalink / raw)
Cc: git
In-Reply-To: <m2fwu2ecy8.fsf@igel.home>
Andreas Schwab [mailto:schwab@linux-m68k.org]
> If they are multiple projects then you'll probably be better off
> importing each project into its own git repository.
>
> Andreas.
Yes, this is probably the 'better' way of dealing with it, and it works
fine. I was however wondering if there was a way to track the root of the
SVN directory with the structure I supplied earlier while maintaining a
'nice' structure in Git without having /trunk/, /branch/, /tag/
subdirectories appearing directly in the repository as standard folders. My
(extremely limited) understanding is that I would need to edit the config
file, specifically the fetch, branches and tags section of svn-remote. But I
am unsure of how this modified section would look like.
Albert
^ permalink raw reply
* [RFC PATCH 2/2] gitweb: use eval + die for error (exception) handling
From: Jakub Narebski @ 2010-12-13 0:49 UTC (permalink / raw)
To: git; +Cc: J.H.
In-Reply-To: <20101213004259.9475.87376.stgit@localhost.localdomain>
In gitweb code it is assumed that calling die_error() subroutine would
end request, just like running "die" would. Up till now it was done by
having die_error() jump to DONE_REQUEST (earlier DONE_GITWEB), or in
earlier version just 'exit' (for mod_perl via ModPerl::Registry it ends
request instead of exiting worker).
Instead of using 'goto DONE_REQUEST' for longjmp-like nonlocal jump, or
using 'exit', gitweb uses now native for Perl exception handlingin the
form of eval / die pair ("eval BLOCK" to trap exceptions, "die LIST" to
raise/throw them).
Up till now the "goto DONE_REQUEST" solution was enough, but with the
coming output caching support and it adding modular structure to gitweb,
it would be difficult to continue to keep using this solution
(e.g. interaction with capturing output).
Because gitweb now traps all exceptions occuring run_request(), the
handle_errors_html handler (set via set_message from CGI::Carp) is not
needed; gitweb can call die_error in -error_handler mode itself. This
has the advantage that we can now set correct HTTP header (handler from
CGI::Carp::set_message was run after HTTP headers were already sent).
Gitweb assumes here that exceptions thrown by Perl would be simple
strings; die_error() throws hash reference (if not for minimal
extrenal dependencies, it would be probable object of Class::Exception
or Throwable class thrown).
Note: in newer versions of CGI::Carp there is set_die_handler(), where
handler have to set HTTP headers to the browser itself, but we cannot
rely on new enough CGI::Carp version to have been installed. Also
set_die_handler interferes with fatalsToBrowser.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is main part of this series.
Comments?
gitweb/gitweb.perl | 26 ++++++++------------------
1 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index af45daa..ab85c53 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -20,7 +20,7 @@ use lib __DIR__ . '/lib';
use CGI qw(:standard :escapeHTML -nosticky);
use CGI::Util qw(unescape);
-use CGI::Carp qw(fatalsToBrowser set_message);
+use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
use File::Find qw();
@@ -1034,21 +1034,6 @@ sub configure_gitweb_features {
}
}
-# custom error handler: 'die <message>' is Internal Server Error
-sub handle_errors_html {
- my $msg = shift; # it is already HTML escaped
-
- # to avoid infinite loop where error occurs in die_error,
- # change handler to default handler, disabling handle_errors_html
- set_message("Error occured when inside die_error:\n$msg");
-
- # you cannot jump out of die_error when called as error handler;
- # the subroutine set via CGI::Carp::set_message is called _after_
- # HTTP headers are already written, so it cannot write them itself
- die_error(undef, undef, $msg, -error_handler => 1, -no_http_header => 1);
-}
-set_message(\&handle_errors_html);
-
# dispatch
sub dispatch {
if (!defined $action) {
@@ -1145,7 +1130,11 @@ sub run {
$pre_dispatch_hook->()
if $pre_dispatch_hook;
- run_request();
+ eval { run_request() };
+ if (defined $@ && !ref($@)) {
+ # some Perl error, but not one thrown by die_error
+ die_error(undef, undef, $@, -error_handler => 1);
+ }
DONE_REQUEST:
$post_dispatch_hook->()
@@ -3670,7 +3659,8 @@ EOF
print "</div>\n";
git_footer_html();
- goto DONE_REQUEST
+
+ die {'status' => $status, 'error' => $error}
unless ($opts{'-error_handler'});
}
^ permalink raw reply related
* [RFC PATCH 1/2] gitweb: Go to DONE_REQUEST rather than DONE_GITWEB in die_error
From: Jakub Narebski @ 2010-12-13 0:48 UTC (permalink / raw)
To: git; +Cc: J.H.
In-Reply-To: <20101213004259.9475.87376.stgit@localhost.localdomain>
End the request after die_error finishes, rather than exiting gitweb
instance (perhaps wrapped like in ModPerl::Registry or gitweb.psgi
case).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch was sent to git mailing list as a standalone RFC patch some
time ago. This version doesn't change anything from previous version.
I am keeping this patch (even though it is not strictly necessary), to
have DONE_REQUEST label, which I think can be quite useful, even if
die_error wouldn't be using it starting from the following commit.
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cfa511c..af45daa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1147,6 +1147,7 @@ sub run {
run_request();
+ DONE_REQUEST:
$post_dispatch_hook->()
if $post_dispatch_hook;
@@ -3669,7 +3670,7 @@ EOF
print "</div>\n";
git_footer_html();
- goto DONE_GITWEB
+ goto DONE_REQUEST
unless ($opts{'-error_handler'});
}
^ permalink raw reply related
* [RFC PATCH 0/2] gitweb: die_error (error handling) improvements
From: Jakub Narebski @ 2010-12-13 0:46 UTC (permalink / raw)
To: git; +Cc: J.H.
The following two patch series changes improve error / exception
handling in gitweb, preparing the way for gitweb output caching, but
useful even without it.
I'm sending this patch series early to gather feedback on possible
ways of improving error / exception handling in gitweb.
Shortlog:
~~~~~~~~~
Jakub Narebski (2):
gitweb: use eval + die for error (exception) handling
gitweb: Go to DONE_REQUEST rather than DONE_GITWEB in die_error
Diffstat:
~~~~~~~~~
gitweb/gitweb.perl | 27 +++++++++------------------
1 files changed, 9 insertions(+), 18 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [PATCH] git_getpass: fix ssh-askpass behaviour
From: Junio C Hamano @ 2010-12-13 0:41 UTC (permalink / raw)
To: Alexander Sulfrian; +Cc: git, Heiko Voigt
In-Reply-To: <1292157174-4033-2-git-send-email-alexander@sulfrian.net>
Alexander Sulfrian <alexander@sulfrian.net> writes:
> call ssh-askpass only if the display environment variable is also set
> ---
I do not use it at all so I don't know for sure, but doesn't this break
OSX?
20f3490 (web--browse: fix Mac OS X GUI detection for 10.6, 2009-09-14)
is an example that you can be fully graphical without having DISPLAY set
in some environment. MinGW folks may want to chime in as well.
> connect.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index 57dc20c..2810e3b 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -621,7 +621,7 @@ int finish_connect(struct child_process *conn)
>
> char *git_getpass(const char *prompt)
> {
> - const char *askpass;
> + const char *askpass, *display;
> struct child_process pass;
> const char *args[3];
> static struct strbuf buffer = STRBUF_INIT;
> @@ -631,7 +631,10 @@ char *git_getpass(const char *prompt)
> askpass = askpass_program;
> if (!askpass)
> askpass = getenv("SSH_ASKPASS");
> - if (!askpass || !(*askpass)) {
> +
> + /* only call askpass if display is set */
> + display = getenv("DISPLAY");
> + if (!display || !(*display) || !askpass || !(*askpass))
> char *result = getpass(prompt);
> if (!result)
> die_errno("Could not read password");
^ permalink raw reply
* Re: [PATCH 1/2] get_sha1_oneline: allow to input commit_list
From: Junio C Hamano @ 2010-12-13 0:29 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Kevin Ballard, Yann Dirson, Jeff King, Jakub Narebski,
Jonathan Niedier, Thiago Farina
In-Reply-To: <1292151419-30678-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> sha1_name.c | 13 ++++++++++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 2c3a5fb..c298285 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -690,7 +690,9 @@ static int handle_one_ref(const char *path,
> return 0;
> }
>
> -static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> +static int get_sha1_oneline(const char *prefix,
> + unsigned char *sha1,
> + struct commit_list *original_list)
> {
> struct commit_list *list = NULL, *backup = NULL, *l;
> int retval = -1;
> @@ -706,7 +708,12 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> if (regcomp(®ex, prefix, REG_EXTENDED))
> die("Invalid search pattern: %s", prefix);
>
> - for_each_ref(handle_one_ref, &list);
> + for (l = original_list; l; l = l->next) {
> + commit_list_insert(l->item, &list);
> + l->item->object.flags |= ONELINE_SEEN;
> + }
> + if (!list)
> + for_each_ref(handle_one_ref, &list);
Two-and-half yucks.
(1) "We work on the list you give us, if you give us one, but we work on
a list we come up with outselves in a magic way otherwise" is an API
designed with a bad taste. Why not make the original caller run
for-each-ref before calling this function?
(2) Why do you have to copy the list, using commit-list-insert, here?
(3) Even if the above extra copy turns out to be needed, do you need yet
another copy in "backup"?
Instead of this patch, I would suggest to go this route:
* Remove local varaible "list" and make it an input parameter.
* Stop calling for-each-ref from this function. Instead, have the
current caller run for-each-ref to prepare list and feed it to you;
* Stop marking commits with "ONELINE_SEEN" from handle-one-ref. Instead,
have the loop to copy list to backup do the marking.
That way, you make the purpose of the function much more clear. It gets a
list of one or more commits that are in date-order, and finds the most
recent commit reachable from them that match the given string, using
ONELINE_SEEN bit as a scratchpad (shouldn't we be using TMP_MARK here, by
the way?). The caller is responsible for giving you a sorted list, but
the caller shouldn't care about ONELINE_SEEN bit.
^ permalink raw reply
* Re: Git SVN non-standard branch/tag/trunk layout
From: Andreas Schwab @ 2010-12-13 0:25 UTC (permalink / raw)
To: Albert Krawczyk; +Cc: git
In-Reply-To: <006c01cb9a44$8407d2f0$8c1778d0$@optusnet.com.au>
"Albert Krawczyk" <pro-logic@optusnet.com.au> writes:
> Essentially instead of having one project per repo, there are multiple
> projects in the repo. So the repo looks like this
>
> ---SVN Root --- Folder(Proj1) ---- Files
> \
> ---- Folder(Proj2) --- Trunk - Files
> | \
> | - Branch - Files
> | |
> | - Tag - ...
> |
> |- Proj3 - Files
> |- Proj4 - Trunk
> |-Branch
> | - Tag
>
> The question is, is there a way I can get Git SVN to understand and
> replicate this layout in a git repo? I don't mind if I have to import the
> entire repo again into git.
If they are multiple projects then you'll probably be better off
importing each project into its own git repository.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Please pull gitk.git master branch
From: Junio C Hamano @ 2010-12-12 23:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <20101212063135.GA7677@brick.ozlabs.ibm.com>
Thanks, pulled (not yet pushed out).
^ permalink raw reply
* developing a modified Linux-style workflow
From: Hans-Christoph Steiner @ 2010-12-12 22:24 UTC (permalink / raw)
To: git
Hey all,
(and my second post on this list...)
I've gotten pretty good at git, and its helping me already with
managing the very odd workflows I have with the software I work a lot
on called Pd (http://puredata.info). My role in Pd development is
like a Linux lieutenant.
I also the main dev for an app called Pd-extended, which is based on
Pd. Now I'm stuck trying to figure out how to use git to match my
current workflow for Pd-extended, which is a kind of long-lived
branch, almost like a friendly fork. So its kind of close to the
Linux workflow with me as a lieutenant, but not quite.
What makes it tricky is that I make releases directly from my repo
that are widely used. So my repo is both lieutenant and dictator at
the same time. So that's where I am stumped. I want to be able to
rebase and push to a public repo, but that would be stupid. So there
has got to be another way.
.hc
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
^ permalink raw reply
* native-style key bindings for gitk on Mac OS X
From: Hans-Christoph Steiner @ 2010-12-12 22:08 UTC (permalink / raw)
To: git
Hey all,
This is my first post here, hopefully I'm not doing anything
stupid ;) I use gitk on Debian, Ubuntu, and Mac OS X. I'm big on
having apps feel native on each platform. Currently gitk's key
bindings are very GNU/Linux-ish when using gitk on Mac OS X. I'd like
to submit a patch to make gitk use native-style key bindings and re-
use common key bindings. F-keys are really rarely used on Mac OS X,
so it drives me a little nuts using them in gitk/Mac OS X.
Before starting this, I just wanted to make sure this isn't some hotly
debated political issue.
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
^ permalink raw reply
* Re: SIGPIPE in t9300-fast-import
From: Brian Gernhardt @ 2010-12-12 22:04 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git@vger.kernel.org List, David Barr
In-Reply-To: <20101212214909.GA19709@burratino>
On Dec 12, 2010, at 4:49 PM, Jonathan Nieder wrote:
> Hmm. Any idea why dd is ending early?
No idea.
> Does using
>
> head -c "$size" >blob <&3 &&
Yes.
> dd of=blob bs=1 count=$size <&3 &&
>
> in its place work?
Yes.
> What does the Mac OS X equivalent of
>
> strace dd of=blob bs=$size count=1 <&3
>
> (dtrace or ktrace, I guess) tell?
The moral equivalent seems to be "dtruss" (which I think is a front end to DTrace) in modern OS X.
0+1 records in
0+1 records out
8139 bytes transferred in 0.000205 secs (39694698 bytes/sec)
SYSCALL(args) = return
ioctl(0x6, 0x80086804, 0x7FFF5FBFD0A0) = 0 0
close(0x6) = 0 0
__sysctl(0x7FFF5FBFCF90, 0x2, 0x7FFF5FBFCF80) = 0 0
bsdthread_register(0x7FFF852F43DC, 0x7FFF852D4FF8, 0x2000) = 0 0
thread_selfid(0x7FFF852F43DC, 0x7FFF852D4FF8, 0x0) = 1850088 0
open_nocancel("/dev/urandom\0", 0x0, 0x7FFF70ABABE0) = 6 0
read_nocancel(0x6, "\350>6\026\310R\251_\227\213h\237\304\330&Q-\247\0313\020BnH\277\337z\276c\247\206\017\340/\302} \2644\273\003\252`\363d8\252\247)V2\323\021\320\\\214\001\331\226\020RY\024I\0", 0x40) = 64 0
close_nocancel(0x6) = 0 0
mmap(0x0, 0x3000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0xD000 0
__sysctl(0x7FFF5FBFCE10, 0x2, 0x7FFF5FBFCDD0) = 0 0
__sysctl(0x7FFF5FBFCDD0, 0x2, 0x7FFF5FBFCE68) = 0 0
getpid(0x7FFF5FBFCD60, 0x7FFFFFE00050, 0x0) = 94596 0
open_nocancel("/dev/urandom\0", 0x0, 0x0) = 6 0
read_nocancel(0x6, "\253\331\354\357A)G\3256\222\024=\242E\261\301\314\351\017K\301;O\256I\270\301\312\263M\307\340+U\217\242\230\335\020\275\356T\323\334\312\313\331*\037\273K\332\a\247\323\324\377m\360\204\375c\026i\345\017x\2070n\026\266\027\021k\340( \245\337\3277H\214\0", 0x6C) = 108 0
close_nocancel(0x6) = 0 0
__sysctl(0x7FFF5FBFCE10, 0x2, 0x7FFF5FBFCE3C) = 0 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0x10000 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0x27000 0
mmap(0x0, 0x1000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0x3E000 0
mmap(0x0, 0x200000, 0x3, 0x1002, 0x7000000, 0x7FFF00000001) = 0x3F000 0
munmap(0x10003F000, 0xC1000) = 0 0
munmap(0x100200000, 0x3F000) = 0 0
__sysctl(0x7FFF5FBFCF70, 0x2, 0x7FFF5FBFCF30) = 0 0
__sysctl(0x7FFF5FBFCF30, 0x2, 0x7FFF70AC7760) = 0 0
__sysctl(0x7FFF5FBFCF70, 0x2, 0x7FFF5FBFCF30) = 0 0
__sysctl(0x7FFF5FBFCF30, 0x2, 0x7FFF70AC7764) = 0 0
__sysctl(0x7FFF5FBFCF70, 0x2, 0x7FFF5FBFCF30) = 0 0
__sysctl(0x7FFF5FBFCF30, 0x2, 0x7FFF70AC7768) = 0 0
mmap(0x0, 0x3000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0x3F000 0
__sysctl(0x7FFF5FBFCF40, 0x2, 0x7FFF5FBFCF00) = 0 0
__sysctl(0x7FFF5FBFCF00, 0x2, 0x7FFF5FBFCF98) = 0 0
__sysctl(0x7FFF5FBFCF40, 0x2, 0x7FFF5FBFCF6C) = 0 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0x42000 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0x59000 0
mmap(0x0, 0x200000, 0x3, 0x1002, 0x7000000, 0x7FFF00000001) = 0x200000 0
munmap(0x100300000, 0x100000) = 0 0
fstat64(0x0, 0x7FFF5FBFF320, 0x17FFF) = 0 0
lseek(0x0, 0x0, 0x1) = -1 Err#29
open("blob\0", 0x602, 0x1B6) = 6 0
fstat64(0x6, 0x7FFF5FBFF320, 0x0) = 0 0
lseek(0x6, 0x0, 0x1) = 0 0
mmap(0x0, 0x58000, 0x3, 0x1002, 0x3000000, 0x7FFF00000000) = 0x70000 0
mmap(0x0, 0x1000, 0x3, 0x1002, 0x3000000, 0x7FFF00000000) = 0xC8000 0
sigaction(0x1D, 0x7FFF5FBFF380, 0x7FFF5FBFF3B0) = 0 0
sigaction(0x2, 0x7FFF5FBFF380, 0x7FFF5FBFF3B0) = 0 0
read(0x0, "the quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the l", 0x2C000) = 8139 0
write(0x6, "the quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the l", 0x1FCB) = 8139 0
write(0x2, "0+1 records in\n0+1 records out\n quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quic", 0x1F) = 31 0
write(0x2, "8139 bytes transferred in 0.000205 secs (39694698 bytes/sec)\nuick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jumps over the lazy dog\nthe quick brown fox jump", 0x3D) = 61 0
getpid(0x7FFF5FBFF250, 0x7FFFFFE00050, 0x0) = 94596 0
open_nocancel("/dev/urandom\0", 0x0, 0x0) = 6 0
read_nocancel(0x6, "\232/\226\373ld\353\r+l\236qV\317\370\271.0\353=\316\3464\t\263\262r\022\362w\360H\245LdE\3769\254\3309m\246I\361\374\307\342]6\n\337\303\310\333\332\036\327\313\224(\3443C\327\224\225\376\221\311-\323\272\344\275l\034\353LR<\236\t\202\250\353\202\276AS\363\023@\353\331[\037\bC\036)\336\363WZ\003\0", 0x6C) = 108 0
close_nocancel(0x6) = 0 0
issetugid(0x100000000, 0x7FFF5FBFF5B0, 0x7FFF5FC40530) = 0 0
geteuid(0x100000000, 0x7FFF5FBFF5B0, 0x0) = 0 0
__sysctl(0x7FFF5FBFD140, 0x2, 0x7FFF5FBFD100) = 0 0
__sysctl(0x7FFF5FBFD100, 0x2, 0x7FFF5FBFD19C) = 0 0
shared_region_check_np(0x7FFF5FBFD308, 0x0, 0x7FFF5FC1DC86) = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF5FBFC710, 0x7FFF5FBFCD50 = 0 0
open("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x0, 0x0) = 6 0
pread(0x6, "\312\376\272\276\0", 0x1000, 0x0) = 4096 0
pread(0x6, "\317\372\355\376\a\0", 0x1000, 0x1000) = 4096 0
mmap(0x100008000, 0x2000, 0x5, 0x12, 0x6, 0x1FFFFFFFF) = 0x8000 0
mmap(0x10000A000, 0x1000, 0x3, 0x12, 0x6, 0x1FFFFFFFF) = 0xA000 0
mmap(0x10000B000, 0x1F10, 0x1, 0x12, 0x6, 0x1FFFFFFFF) = 0xB000 0
close(0x6) = 0 0
stat64("/usr/lib/libSystem.B.dylib\0", 0x7FFF5FBFC4C0, 0x7FFF5FBFCB00) = 0 0
stat64("/usr/lib/system/libmathCommon.A.dylib\0", 0x7FFF5FBFC370, 0x7FFF5FBFC9B0) = 0 0
madvise(0x7FFF89610000, 0x2000, 0x5) = 0 0
open("/dev/dtracehelper\0", 0x2, 0x7FFF5FC45258) = 6 0
ioctl(0x6, 0x80086804, 0x7FFF5FBFD0A0) = 0 0
close(0x6) = 0 0
stat64("/usr/lib/libstdc++.6.dylib\0", 0x7FFF5FBFC4B0, 0x7FFF5FBFCAF0) = 0 0
open("/dev/dtracehelper\0", 0x2, 0x7FFF5FC45320) = 6 0
error: git-fast-import died of signal 13
---- 8< ----
blob does exist, it just seems to end early:
--- big 2010-12-12 16:56:32.000000000 -0500
+++ blob 2010-12-12 16:56:33.000000000 -0500
@@ -182,3915 +182,4 @@
Followed by many lines of:
-the quick brown fox jumps over the lazy dog
and then:
+the quick brown fox jumps over the lazy dog
\ No newline at end of file
> Thanks for noticing.
I tend to update to latest next, compile, and test about once a day so exactly so I can catch things. :-D
~~ Brian
^ permalink raw reply
* Re: SIGPIPE in t9300-fast-import
From: Jonathan Nieder @ 2010-12-12 21:49 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git@vger.kernel.org List, David Barr
In-Reply-To: <0BB1933F-1C3D-4C24-9C91-263121BF55FB@gernhardtsoftware.com>
Brian Gernhardt wrote:
> read blob_id type size <&3 &&
> echo "$blob_id $type $size" >response &&
> dd of=blob bs=$size count=1 <&3 &&
[...]
> 0+1 records in
> 0+1 records out
> 8139 bytes transferred in 0.000062 secs (131297847 bytes/sec)
> error: git-fast-import died of signal 13
[...]
> I can run help provide diagnostics, if anyone needs more data.
Hmm. Any idea why dd is ending early? Does using
head -c "$size" >blob <&3 &&
or
dd of=blob bs=1 count=$size <&3 &&
in its place work? What does the Mac OS X equivalent of
strace dd of=blob bs=$size count=1 <&3
(dtrace or ktrace, I guess) tell?
Thanks for noticing.
^ permalink raw reply
* Git SVN non-standard branch/tag/trunk layout
From: Albert Krawczyk @ 2010-12-12 21:35 UTC (permalink / raw)
To: git
Hi all,
One of the SVN repositories that I work with (and have a Git version of) has
recently implemented a tag/trunk/branch layout, and I'd like to update my
repository to correctly work with this layout.
As far as I understand the standard layout for a SVN repo that supports
branching is
SVR Root ----Trunk - folders/files
\
--Branch - folders/files
\
-Tag - folders/files
With each of those having the project contents
The SVN repo I am now faced with has the trunk/branch/tag folders on
selected folders in the tree.
Essentially instead of having one project per repo, there are multiple
projects in the repo. So the repo looks like this
---SVN Root --- Folder(Proj1) ---- Files
\
---- Folder(Proj2) --- Trunk - Files
| \
| - Branch - Files
| |
| - Tag - ...
|
|- Proj3 - Files
|- Proj4 - Trunk
|-Branch
| - Tag
The question is, is there a way I can get Git SVN to understand and
replicate this layout in a git repo? I don't mind if I have to import the
entire repo again into git.
Thanks,
Albert
^ permalink raw reply
* SIGPIPE in t9300-fast-import
From: Brian Gernhardt @ 2010-12-12 20:49 UTC (permalink / raw)
To: git@vger.kernel.org List; +Cc: David Barr
The new cat-blob test (9300.114) is failing for me on OS X, and has been since it's introduction in "85c6239 fast-import: let importers retrieve blobs":
---- 8< ----
ok 113 - setup: have pipes?
expecting success:
expect_id=$(git hash-object big) &&
expect_len=$(wc -c <big) &&
echo $expect_id blob $expect_len >expect.response &&
rm -f blobs &&
cat >frontend <<-\FRONTEND_END &&
#!/bin/sh
cat <<EOF &&
feature cat-blob
blob
mark :1
data <<BLOB
EOF
cat big
cat <<EOF
BLOB
cat-blob :1
EOF
read blob_id type size <&3 &&
echo "$blob_id $type $size" >response &&
dd of=blob bs=$size count=1 <&3 &&
read newline <&3 &&
cat <<EOF &&
commit refs/heads/copied
committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
data <<COMMIT
copy big file as file3
COMMIT
M 644 inline file3
data <<BLOB
EOF
cat blob &&
cat <<EOF
BLOB
EOF
FRONTEND_END
mkfifo blobs &&
(
export GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE &&
sh frontend 3<blobs |
git fast-import --cat-blob-fd=3 3>blobs
) &&
git show copied:file3 >actual &&
test_cmp expect.response response &&
test_cmp big actual
0+1 records in
0+1 records out
8139 bytes transferred in 0.000062 secs (131297847 bytes/sec)
error: git-fast-import died of signal 13
not ok - 114 R: copy using cat-file
---- 8< ----
I don't have the tuits right now to dig into this, but "trash directory.t9300-fast-input" has a good response (`cmp expect.response response` is true), but has no refs/heads/copied. I can run help provide diagnostics, if anyone needs more data.
~~ Brian
PS: Isn't t9300 getting a little crazily long? Is there a good way to split it up by feature or something? It runs quickly, but finding were something is failing is getting a little difficult.
^ 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