Michael J Gruber [off-list ref] writes:
quoted
quoted
+ if (!parent || parse_commit(parent->item) || parse_tree(parent->item->tree) ||
+ hashcmp(parent->item->tree->object.sha1, tree_sha1)) {
I didn't check, but I can imagine you can drop the parse_tree here. We
should know the object sha1 once the commit is parsed.
parse_commit() does a lookup_tree() but I don't think that it parses the
tree, i.e. I don't hink it fills in tree->object.sha1.
Huh? parse_tree(tree) calls read_sha1_file(tree->object.sha1) to parse
the tree. How can it do without filling tree->object.sha1?
Junio C Hamano venit, vidit, dixit 31.08.2010 18:44:
Michael J Gruber [off-list ref] writes:
quoted
quoted
quoted
+ if (!parent || parse_commit(parent->item) || parse_tree(parent->item->tree) ||
+ hashcmp(parent->item->tree->object.sha1, tree_sha1)) {
I didn't check, but I can imagine you can drop the parse_tree here. We
should know the object sha1 once the commit is parsed.
parse_commit() does a lookup_tree() but I don't think that it parses the
tree, i.e. I don't hink it fills in tree->object.sha1.
Huh? parse_tree(tree) calls read_sha1_file(tree->object.sha1) to parse
the tree. How can it do without filling tree->object.sha1?
Sure parse_tree() does that. That's why I call it. I never claimed it
doesn't.
Michael
On Tue, Aug 31, 2010 at 08:26:34PM +0200, Michael J Gruber wrote:
Junio C Hamano venit, vidit, dixit 31.08.2010 18:44:
quoted
Michael J Gruber [off-list ref] writes:
quoted
quoted
quoted
+ if (!parent || parse_commit(parent->item) || parse_tree(parent->item->tree) ||
+ hashcmp(parent->item->tree->object.sha1, tree_sha1)) {
I didn't check, but I can imagine you can drop the parse_tree here. We
should know the object sha1 once the commit is parsed.
parse_commit() does a lookup_tree() but I don't think that it parses the
tree, i.e. I don't hink it fills in tree->object.sha1.
Huh? parse_tree(tree) calls read_sha1_file(tree->object.sha1) to parse
the tree. How can it do without filling tree->object.sha1?
Sure parse_tree() does that. That's why I call it. I never claimed it
doesn't.
I think the claim is that it is already parsed. Look at parse_tree. The
first non-declaration lines are:
if (item->object.parsed)
return 0;
buffer = read_sha1_file(item->object.sha1, &type, &size);
So _somebody_ has already filled in item->object.sha1.
-Peff
Jeff King venit, vidit, dixit 31.08.2010 20:29:
On Tue, Aug 31, 2010 at 08:26:34PM +0200, Michael J Gruber wrote:
quoted
Junio C Hamano venit, vidit, dixit 31.08.2010 18:44:
quoted
Michael J Gruber [off-list ref] writes:
quoted
quoted
quoted
+ if (!parent || parse_commit(parent->item) || parse_tree(parent->item->tree) ||
+ hashcmp(parent->item->tree->object.sha1, tree_sha1)) {
I didn't check, but I can imagine you can drop the parse_tree here. We
should know the object sha1 once the commit is parsed.
parse_commit() does a lookup_tree() but I don't think that it parses the
tree, i.e. I don't hink it fills in tree->object.sha1.
Huh? parse_tree(tree) calls read_sha1_file(tree->object.sha1) to parse
the tree. How can it do without filling tree->object.sha1?
Sure parse_tree() does that. That's why I call it. I never claimed it
doesn't.
I think the claim is that it is already parsed. Look at parse_tree. The
first non-declaration lines are:
if (item->object.parsed)
return 0;
buffer = read_sha1_file(item->object.sha1, &type, &size);
So _somebody_ has already filled in item->object.sha1.
-Peff
OK, now I understand Junio's answer...
...and I also see where lookup_tree() fills the sha1, which I failed to
see before.
I guess what happened was that I had the parse_tree without
parse_commit, which segfaulted, and then inserted parse_commit.
In any case, it seems Johan is going with his approach, so you can
forget about the RFC, be it with or without parse_tree.
Michael