git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] technical-docs: document tree-walking API
@ 2009-08-04  4:13 Stephen Boyd
  2009-08-04  5:38 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Boyd @ 2009-08-04  4:13 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---

This is a minor update incorporating feedback from Junio. Plus, I decided to
add an authors section.

 Documentation/technical/api-tree-walking.txt |  147 ++++++++++++++++++++++++--
 1 files changed, 140 insertions(+), 7 deletions(-)

diff --git a/Documentation/technical/api-tree-walking.txt b/Documentation/technical/api-tree-walking.txt
index e3ddf91..5b03199 100644
--- a/Documentation/technical/api-tree-walking.txt
+++ b/Documentation/technical/api-tree-walking.txt
@@ -1,12 +1,145 @@
 tree walking API
 ================
 
-Talk about <tree-walk.h>, things like
+The tree walking API is used to traverse and inspect trees.
 
-* struct tree_desc
-* init_tree_desc
-* tree_entry_extract
-* update_tree_entry
-* get_tree_entry
+Data Structures
+---------------
 
-(JC, Linus)
+`struct name_entry`::
+
+	An entry in a tree. Each entry has a sha1 identifier, pathname, and
+	mode.
+
+`struct tree_desc`::
+
+	A semi-opaque data structure used to maintain the current state of the
+	walk. 
++
+* `buffer` is a pointer into the memory representation of the tree. It always
+points at the current entry being visited.
+
+* `size` counts the number of bytes left in the `buffer`.
+
+* `entry` points to the current entry being visited.
+
+`struct traverse_info`::
+
+	A structure used to maintain the state of a traversal.
++
+* `prev` points to the traverse_info which was used to descend into the
+current tree. If this is the top-level tree `prev` will point to
+a dummy traverse_info. 
+
+* `name` is the entry for the current tree (if the tree is a subtree).
+
+* `pathlen` is the length of the full path for the current tree.
+
+* `conflicts` can be used by callbacks to maintain directory-file conflicts.
+
+* `fn` is a callback called for each entry in the tree. See Traversing for more
+information.
+
+* `data` can be anything the `fn` callback would want to use.
+
+Initializing
+------------
+
+`init_tree_desc`::
+
+	Initialize a `tree_desc` and decode its first entry. The buffer and
+	size parameters are assumed to be the same as the buffer and size
+	members of `struct tree`.
+
+`fill_tree_descriptor`::
+
+	Initialize a `tree_desc` and decode its first entry given the sha1 of
+	a tree. Returns the `buffer` member if the sha1 is a valid tree
+	identifier and NULL otherwise.
+
+`setup_traverse_info`::
+
+	Initialize a `traverse_info` given the pathname of the tree to start
+	traversing from. The `base` argument is assumed to be the `path`
+	member of the `name_entry` being recursed into unless the tree is a
+	top-level tree in which case the empty string ("") is used.
+
+Walking
+-------
+
+`tree_entry`::
+
+	Visit the next entry in a tree. Returns 1 when there are more entries
+	left to visit and 0 when all entries have been visited. This is
+	commonly used in the test of a while loop.
+
+`tree_entry_len`::
+
+	Calculate the length of a tree entry's pathname. This utilizes the
+	memory structure of a tree entry to avoid the overhead of using a
+	generic strlen().
+
+`update_tree_entry`::
+
+	Walk to the next entry in a tree. This is commonly used in conjunction
+	with `tree_entry_extract` to inspect the current entry.
+
+`tree_entry_extract`::
+
+	Decode the entry currently being visited (the one pointed to by
+	`tree_desc's` `entry` member) and return the sha1 of the entry. The
+	`pathp` and `modep` arguments are set to the entry's pathname and mode
+	respectively.
+
+`get_tree_entry`::
+
+	Find an entry in a tree given a pathname and the sha1 of a tree to
+	search. Returns 0 if the entry is found and -1 otherwise. The third
+	and fourth parameters are set to the entry's sha1 and mode
+	respectively.
+
+Traversing
+----------
+
+`traverse_trees`::
+
+	Traverse `n` number of trees in parallel. The `fn` callback member of
+	`traverse_info` is called once for each tree entry.
+
+`traverse_callback_t`::
+	The arguments passed to the traverse callback are as follows:
++
+* `n` counts the number of trees being traversed.
+
+* `mask` has its nth bit set if something exists in the nth entry.
+
+* `dirmask` has its nth bit set if the nth tree's entry is a directory.
+
+* `entry` is an array of size `n` where the nth entry is from the nth tree.
+
+* `info` maintains the state of the traversal.
+
++
+Returning a negative value will terminate the traversal. Otherwise the
+return value is treated as an update mask. If the nth bit is set the nth tree
+will be updated and if the bit is not set the nth tree entry will be the
+same in the next callback invocation.
+
+`make_traverse_path`::
+
+	Generate the full pathname of a tree entry based from the root of the
+	traversal. For example, if the traversal has recursed into another
+	tree named "bar" the pathname of an entry "baz" in the "bar"
+	tree would be "bar/baz".
+
+`traverse_path_len`::
+
+	Calculate the length of a pathname returned by `make_traverse_path`.
+	This utilizes the memory structure of a tree entry to avoid the
+	overhead of using a generic strlen().
+
+Authors
+-------
+
+Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds
+<torvalds@linux-foundation.org>
-- 
1.6.4.GIT

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] technical-docs: document tree-walking API
  2009-08-04  4:13 [PATCH] technical-docs: document tree-walking API Stephen Boyd
@ 2009-08-04  5:38 ` Junio C Hamano
  2009-08-04  6:00   ` Stephen Boyd
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2009-08-04  5:38 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: git

Stephen Boyd <bebarino@gmail.com> writes:

> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> This is a minor update incorporating feedback from Junio. Plus, I decided to
> add an authors section.

I think the primary author is Linus for this API, but once you finished
the documentation, I do not think "authors" section is particularly
needed (git knows who the code came from reasonably well anyway).  The
names of people in these stub documents were there for people like you;
see 530e741 (Start preparing the API documents., 2007-11-24).

It might be a bit misleading to say that the path member of struct
name_entry is a "pathname".  It is _one_ path component, and by stringing
multiple struct traverse_info's (each of which has one struct name_entry)
together with their prev pointer, make_traverse_path() can reconstruct the
full pathname from the toplevel down to the level you have traversed into.
We may want to say "path component" to clarify the distinction.

But these are minor points.  I'll apply the patch as-is.

Thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] technical-docs: document tree-walking API
  2009-08-04  5:38 ` Junio C Hamano
@ 2009-08-04  6:00   ` Stephen Boyd
  0 siblings, 0 replies; 3+ messages in thread
From: Stephen Boyd @ 2009-08-04  6:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio C Hamano wrote:
> I think the primary author is Linus for this API, but once you finished
> the documentation, I do not think "authors" section is particularly
> needed (git knows who the code came from reasonably well anyway).  The
> names of people in these stub documents were there for people like you;
> see 530e741 (Start preparing the API documents., 2007-11-24).

I'm ok with dropping the Authors section then.

>
> It might be a bit misleading to say that the path member of struct
> name_entry is a "pathname".  It is _one_ path component, and by stringing
> multiple struct traverse_info's (each of which has one struct name_entry)
> together with their prev pointer, make_traverse_path() can reconstruct the
> full pathname from the toplevel down to the level you have traversed into.
> We may want to say "path component" to clarify the distinction.

This sounds reasonable for the traversing section. I'm a bit confused
about how it would work for the walking section though. I don't get the
notion of path components there because the API is focused around one
level of a tree. Maybe it should just be called the entry's name in that
case?

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-08-04  6:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-04  4:13 [PATCH] technical-docs: document tree-walking API Stephen Boyd
2009-08-04  5:38 ` Junio C Hamano
2009-08-04  6:00   ` Stephen Boyd

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).