From: Junio C Hamano <gitster@pobox.com>
To: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Cc: "Shawn O. Pearce" <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: [PATCH 1/4] add generic, type aware object chain walker
Date: Sun, 24 Feb 2008 19:08:39 -0800 [thread overview]
Message-ID: <7vr6f1pwaw.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 12038642373342-git-send-email-mkoegler@auto.tuwien.ac.at
Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> diff --git a/Makefile b/Makefile
> index a9b5a67..3b356f8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -303,7 +303,7 @@ LIB_H = \
> run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
> tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
> utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
> - mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h ll-merge.h
> + mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h ll-merge.h fsck.h
I'd rather see a series does not depend on things in next that
you do not have to depend on, pretty please?
The patches have style issues everywhere. The opening paren
that surrounds the conditional to if/while should always have a
SP before it, while function names at the function callsite
should immediately be followed by an open paren.
> +static int fsck_walk_tree(struct tree *tree, fsck_walk_func walk, void *data)
> +{
> + struct tree_desc desc;
> + struct name_entry entry;
> +
> + if(parse_tree(tree))
> + return -1;
> +
> + init_tree_desc(&desc, tree->buffer, tree->size);
> + while(tree_entry(&desc, &entry)) {
> + int result;
> +
> + if (S_ISGITLINK(entry.mode))
> + continue;
> + if (S_ISDIR(entry.mode))
> + result = walk(&lookup_tree(entry.sha1)->object, OBJ_TREE, data);
> + else if (S_ISREG(entry.mode) || S_ISLNK(entry.mode))
> + result = walk(&lookup_blob(entry.sha1)->object, OBJ_BLOB, data);
> + else {
> + error("in tree %s: entry %s has bad mode %.6o\n",
> + sha1_to_hex(tree->object.sha1), entry.path, entry.mode);
> + result = -1;
> + }
Would "result = error(...)" be too cute ;-)?
> +static int fsck_walk_commit(struct commit *commit, fsck_walk_func walk, void *data)
> +{
> + struct commit_list *parents = commit->parents;
> + int result;
> +
> + if(parse_commit(commit))
> + return -1;
> +
> + result = walk((struct object*)commit->tree, OBJ_TREE, data);
> + if (result)
> + return result;
> +
> + while (parents) {
> + result = walk((struct object*)parents->item, OBJ_COMMIT, data);
> + if (result)
> + return result;
> + parents = parents->next;
> + }
> + return 0;
> +}
Hmm. For the purpose of proving there is _no_ error (or an
error or more), it would be Ok to return early like this, but
won't there be cases where you would want to get as many
coverage as possible?
For example, I do not think you can use this to mark reachable
objects. Even if you find error walking the first parent
history, you would want to still mark a healthy second parent
history reachable.
> diff --git a/fsck.h b/fsck.h
> new file mode 100644
> index 0000000..fccc89f
> --- /dev/null
> +++ b/fsck.h
> @@ -0,0 +1,10 @@
> +#ifndef GIT_FSCK_H
> +#define GIT_FSCK_H
> +
> +#define OBJ_ANY OBJ_BAD
> +
> +typedef int (*fsck_walk_func)(struct object *obj, int type, void *data);
It is unclear in this patch, but this "type" is not telling what
the type of the object is to the walk_func, but is telling it
that the given object was found in a place where object of that
type is expected/required, so that walk_func can check and
complain, right? Needs a bit of commenting...
next prev parent reply other threads:[~2008-02-25 3:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-24 14:43 [PATCH 1/4] add generic, type aware object chain walker Martin Koegler
2008-02-24 14:43 ` [PATCH 2/4] builtin-fsck: move away from object-refs Martin Koegler
2008-02-24 14:43 ` [PATCH 3/4] Remove unused object-ref code Martin Koegler
2008-02-24 14:43 ` [PATCH 4/4] builtin-fsck: reports missing parent commits Martin Koegler
2008-02-25 3:04 ` [PATCH 1/4] add generic, type aware object chain walker Shawn O. Pearce
2008-02-25 7:26 ` Martin Koegler
2008-02-25 7:37 ` Junio C Hamano
2008-02-25 7:52 ` Martin Koegler
2008-02-25 8:02 ` Junio C Hamano
2008-02-25 8:06 ` Martin Koegler
2008-02-25 8:12 ` Shawn O. Pearce
2008-02-25 17:35 ` Nicolas Pitre
2008-02-25 8:04 ` Shawn O. Pearce
2008-02-25 17:49 ` Nicolas Pitre
2008-02-25 3:08 ` Junio C Hamano [this message]
2008-02-25 7:46 ` Martin Koegler
2008-02-25 7:59 ` Junio C Hamano
2008-02-25 8:21 ` Martin Koegler
2008-02-25 8:10 ` Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vr6f1pwaw.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mkoegler@auto.tuwien.ac.at \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).