Yeah, I just grepped for users of parse_commit(), and there are just too
many, so this change makes sense.
This makes sense, too.
I'd rather have this return NULL after displaying an error. After all,
merge_bases() is sort of "libified".
BTW a simple "git grep parse_commit\( | grep -vwe if -e gitweb" shows
this:
builtin-blame.c: parse_commit(commit);
builtin-checkout.c: parse_commit(commit);
builtin-checkout.c: parse_commit(old->commit);
builtin-checkout.c: parse_commit(new->commit);
builtin-checkout.c: parse_commit(new.commit);
builtin-describe.c: parse_commit(p);
builtin-describe.c: parse_commit(p);
builtin-fast-export.c: parse_commit(commit);
builtin-fast-export.c: parse_commit(commit->parents->item);
builtin-fetch-pack.c: parse_commit(commit);
builtin-fetch-pack.c: parse_commit(commit);
builtin-fetch-pack.c: parse_commit(commit);
builtin-name-rev.c: parse_commit(commit);
builtin-show-branch.c: parse_commit(p);
builtin-show-branch.c: parse_commit(commit);
commit.c:int parse_commit(struct commit *item)
commit.c: parse_commit(commit);
commit.c: parse_commit(one);
commit.c: parse_commit(two);
commit.c: parse_commit(p);
commit.h:int parse_commit(struct commit *item);
contrib/gitview/gitview: self.parse_commit(commit_lines)
contrib/gitview/gitview: def parse_commit(self, commit_lines):
shallow.c: parse_commit(commit);
upload-pack.c: parse_commit((struct commit *)object);
A few of those need checking, too, I think.
Again, please do not die() in merge_bases().
IMHO not needed [*1*]. The first user of this (static) function calls it
with lookup_blob(), which assumes that the blob has been read already.
The second uses a checked object.
Same here.
Can parents->item really be NULL? I think not. And indeed, a little
search reveals that parse_commit_buffer() does this when it constructs the
parents list, and encounters an invalid SHA-1:
return error("bad parents in commit %s", sha1_to_hex(item->object.sha1));
In case it is a valid SHA-1, but not a commit, it is ignored.
I haven't looked yet, but I suspect that this is as impossible as the
invalid parent.
See above.
See above.
Makes sense.
See above.
See above.
You probably want to guard for ((tag *)o)->tagged == NULL; Okay, now I am
curious. *megoesandlooks* Indeed, if the tag refers to an unknown type,
tagged = NULL.
But I think in that case, it should return an error(). And maybe only for
type == OBJ_TAG.
As above, it looks strange to see that object->something is checked, and
_then_ object. I'd put this into curly brackets, together with the
deref_tag(), just to help the reader a bit, should she be as weak in mind
as yours truly.
Makes sense, but please add a space after the "if".
Knowing that tagged _can_ be NULL, this makes tons of sense. Except that
again, I'd call error() to tell the user, before setting o = NULL.
Ciao,
Dscho
[*1*] There might be a few people arguing that defensive programming is
never wrong.
Alas, I saw my share of defensive programming, and more often than not,
the real bugs were hard to find in between all those checks. And some
checks were actively wrong -- again hard to see...
Remember: You can make code so simple that there are obviously no bugs.
And the other way is to make it so complicated that there are no obvious
bugs.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html