path: root/revision.c
AgeCommit message (Collapse)Author
2007-01-09Sanitize for_each_reflog_ent()Johannes Schindelin
It used to ignore the return value of the helper function; now, it expects it to return 0, and stops iteration upon non-zero return values; this value is then passed on as the return value of for_each_reflog_ent(). Further, it makes no sense to force the parsing upon the helper functions; for_each_reflog_ent() now calls the helper function with old and new sha1, the email, the timestamp & timezone, and the message. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2006-12-30Move commit reencoding parameter parsing to revision.cJunio C Hamano
This way, git-rev-list and git-diff-tree with --pretty can use it. Signed-off-by: Junio C Hamano <>
2006-12-27Merge branch 'jc/fsck-reflog'Junio C Hamano
* jc/fsck-reflog: Add git-reflog to .gitignore reflog expire: do not punt on tags that point at non commits. reflog expire: prune commits that are not incomplete Don't crash during repack of a reflog with pruned commits. git reflog expire Move in_merge_bases() to commit.c reflog: fix warning message. Teach git-repack to preserve objects referred to by reflog entries. Protect commits recorded in reflog from pruning. add for_each_reflog_ent() iterator
2006-12-25Merge branch 'jc/skip-count'Junio C Hamano
* jc/skip-count: revision: --skip=<n>
2006-12-22Don't crash during repack of a reflog with pruned commits.Shawn O. Pearce
If the user has been using reflog for a long time (e.g. since its introduction) then it is very likely that an existing branch's reflog may still mention commits which have long since been pruned out of the repository. Rather than aborting with a very useless error message during git-repack, pack as many valid commits as we can get from the reflog and let the user know that the branch's reflog contains already pruned commits. A future 'git reflog expire' (or whatever it finally winds up being called) can then be performed to expunge those reflog entries. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2006-12-21Teach git-repack to preserve objects referred to by reflog entries.Junio C Hamano
This adds a new option --reflog to pack-objects and revision machinery; do not bother documenting it for now, since this is only useful for local repacking. When the option is passed, objects reachable from reflog entries are marked as interesting while computing the set of objects to pack. Signed-off-by: Junio C Hamano <>
2006-12-20Merge branch 'jc/leftright'Junio C Hamano
* jc/leftright: Revert "Make left-right automatic." Make left-right automatic. Teach all of log family --left-right output. rev-list --left-right
2006-12-20revision: --skip=<n>Junio C Hamano
This adds --skip=<n> option to revision traversal machinery. Documentation and test were added by Robert Fitzsimons. Signed-off-by: Robert Fitzsimons <> Signed-off-by: Junio C Hamano <>
2006-12-20simplify inclusion of system header files.Junio C Hamano
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <>
2006-12-19Revert "Make left-right automatic."Junio C Hamano
This reverts commit 5761231975ceffa531d86d9bab0f9a9a370674f6. Feeding symmetric difference to gitk is so useful, and it is the same for other graphical Porcelains. Rather than forcing them to pass --no-left-right, making it optional. Noticed and reported by Jeff King.
2006-12-17Make left-right automatic.Junio C Hamano
When using symmetric differences, I think the user almost always would want to know which side of the symmetry each commit came from. So this removes --left-right option from the command line, and turns it on automatically when a symmetric difference is used ("git log --merge" counts as a symmetric difference between HEAD and MERGE_HEAD). Just in case, a new option --no-left-right is provided to defeat this, but I do not know if it would be useful. Signed-off-by: Junio C Hamano <>
2006-12-17Teach all of log family --left-right output.Junio C Hamano
This makes reviewing git log --left-right --merge --no-merges -p a lot more pleasant. Signed-off-by: Junio C Hamano <>
2006-12-17rev-list --left-rightJunio C Hamano
The output from "symmetric diff", i.e. A...B, does not distinguish between commits that are reachable from A and the ones that are reachable from B. In this picture, such a symmetric diff includes commits marked with a and b. x---b---b branch B / \ / / . / / \ o---x---a---a branch A However, you cannot tell which ones are 'a' and which ones are 'b' from the output. Sometimes this is frustrating. This adds an output option, --left-right, to rev-list. rev-list --left-right A...B would show ones reachable from A prefixed with '<' and the ones reachable from B prefixed with '>'. When combined with --boundary, boundary commits (the ones marked with 'x' in the above picture) are shown with prefix '-', so you would see list that looks like this: git rev-list --left-right --boundary --pretty=oneline A...B >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a Signed-off-by: Junio C Hamano <>
2006-11-08Merge branch 'jc/pickaxe'Junio C Hamano
2006-11-01Merge branch 'lj/refs'Junio C Hamano
* lj/refs: (63 commits) Fix show-ref usagestring t3200: git-branch testsuite update sha1_name.c: avoid compilation warnings. Make git-branch a builtin ref-log: fix D/F conflict coming from deleted refs. git-revert with conflicts to behave as git-merge with conflicts core.logallrefupdates thinko-fix git-pack-refs --all core.logallrefupdates create new log file only for branch heads. Remove bashism from ref-log: allow ref@{count} syntax. pack-refs: call fflush before fsync. pack-refs: use lockfile as everybody else does. git-fetch: do not look into $GIT_DIR/refs to see if a tag exists. lock_ref_sha1_basic does not remove empty directories on BSD Do not create tag leading directories since git update-ref does it. Check that a tag exists using show-ref instead of looking for the ref file. Use git-update-ref to delete a tag instead of rm()ing the ref file. Fix refs.c;:repack_without_ref() clean-up path Clean up "" and add remove recursive dir test cases. ...
2006-10-31Introduce a new revision set operator <rev>^!Junio C Hamano
This is a shorthand for "<rev> --not <rev>^@", i.e. "include this commit but exclude any of its parents". When a new file $F is introduced by revision $R, this notation can be used to find a copy-and-paste from existing file in the parents of that revision without annotating the ancestry of the lines that were copied from: git pickaxe -f -C $R^! -- $F Signed-off-by: Junio C Hamano <>
2006-10-31Merge branch 'maint'Junio C Hamano
* maint: revision traversal: --unpacked does not limit commit list anymore. Continue traversal when rev-list --unpacked finds a packed commit. Use memmove instead of memcpy for overlapping areas quote.c: ensure the same quoting across platforms. Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
2006-10-31revision traversal: --unpacked does not limit commit list anymore.Junio C Hamano
This is needed to gain smaller latency back. Signed-off-by: Junio C Hamano <>
2006-10-31Continue traversal when rev-list --unpacked finds a packed commit.Jan Harkes
When getting the list of all unpacked objects by walking the commit history, we would stop traversal whenever we hit a packed commit. However the fact that we found a packed commit does not guarantee that all previous commits are also packed. As a result the commit walkers did not show all reachable unpacked objects. Signed-off-by: Jan Harkes <> Signed-off-by: Junio C Hamano <>
2006-09-28teach revision walker about --all-match.Junio C Hamano
This lets you say: git log --all-match --author=Linus --committer=Junio --grep=rev-list to limit commits that was written by Linus, committed by me and the log message contains word "rev-list". Signed-off-by: Junio C Hamano <>
2006-09-28Merge branch 'master' into lj/refsJunio C Hamano
* master: (72 commits) runstatus: do not recurse into subdirectories if not needed grep: fix --fixed-strings combined with expression. grep: free expressions and patterns when done. Corrected copy-and-paste thinko in ignore executable bit test case. An illustration of rev-list --parents --pretty=raw Allow git-checkout when on a non-existant branch. gitweb: Decode long title for link tooltips git-svn: Fix fetch --no-ignore-externals with GIT_SVN_NO_LIB=1 Ignore executable bit when adding files if filemode=0. Remove empty ref directories that prevent creating a ref. Use const for interpolate arguments git-archive: update documentation Deprecate gitweb: fix over-eager application of esc_html(). Allow '(no author)' in git-svn's authors file. Allow 'svn fetch' on '(no date)' revisions in Subversion. git-repack: allow git-repack to run in subdirectory Remove upload-tar and make git-tar-tree a thin wrapper to git-archive git-tar-tree: Move code for git-archive --format=tar to archive-tar.c git-tar-tree: Remove duplicate git_config() call ...
2006-09-21Tell between packed, unpacked and symbolic refs.Junio C Hamano
This adds a "int *flag" parameter to resolve_ref() and makes for_each_ref() family to call callback function with an extra "int flag" parameter. They are used to give two bits of information (REF_ISSYMREF and REF_ISPACKED) about the ref. Signed-off-by: Junio C Hamano <>
2006-09-21Add callback data to for_each_ref() family.Junio C Hamano
This is a long overdue fix to the API for for_each_ref() family of functions. It allows the callers to specify a callback data pointer, so that the caller does not have to use static variables to communicate with the callback funciton. The updated for_each_ref() family takes a function of type int (*fn)(const char *, const unsigned char *, void *) and a void pointer as parameters, and calls the function with the name of the ref and its SHA-1 with the caller-supplied void pointer as parameters. The commit updates two callers, builtin-name-rev.c and builtin-pack-refs.c as an example. Signed-off-by: Junio C Hamano <>
2006-09-20git log: Unify header_filter and message_filter into one.Junio C Hamano
Now we can tell the built-in grep to grep only in head or in body, use that to update --author, --committer, and --grep. Unfortunately, to make --and, --not and other grep boolean expressions useful, as in: # Things written by Junio committed and by Linus and log # does not talk about diff. git log --author=Junio --and --committer=Linus \ --grep-not --grep=diff we will need to do another round of built-in grep core enhancement, because grep boolean expressions are designed to work on one line at a time. Signed-off-by: Junio C Hamano <>
2006-09-20git-log --author and --committer are not left-anchored by defaultLinus Torvalds
I know that I'd prefer a rule where "--author=^Junio" would result in the grep-pattern being "^author Junio", but without the initial '^' it would be "^author .*Junio". Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-09-20revision traversal: --author, --committer, and --grep.Junio C Hamano
This adds three options to setup_revisions(), which lets you filter resulting commits by the author name, the committer name and the log message with regexp. Signed-off-by: Junio C Hamano <>
2006-09-20revision traversal: prepare for commit log match.Junio C Hamano
This is from a suggestion by Linus, just to mark the locations where we need to modify to actually implement the filtering. We do not have any actual filtering code yet. Signed-off-by: Junio C Hamano <>
2006-09-07pack-objects --unpacked=<existing pack> option.Junio C Hamano
Incremental repack without -a essentially boils down to: rev-list --objects --unpacked --all | pack-objects $new_pack which picks up all loose objects that are still live and creates a new pack. This implements --unpacked=<existing pack> option to tell the revision walking machinery to pretend as if objects in such a pack are unpacked for the purpose of object listing. With this, we could say: rev-list --objects --unpacked=$active_pack --all | pack-objects $new_pack instead, to mean "all live loose objects but pretend as if objects that are in this pack are also unpacked". The newly created pack would be perfect for updating $active_pack by replacing it. Since pack-objects now knows how to do the rev-list's work itself internally, you can also write the above example by: pack-objects --unpacked=$active_pack --all $new_pack </dev/null Signed-off-by: Junio C Hamano <>
2006-09-06revision.c: allow injecting revision parameters after setup_revisions().Junio C Hamano
setup_revisions() wants to get all the parameters at once and then postprocesses the resulting revs structure after it is done with them. This code structure is a bit cumbersome to deal with efficiently when we want to inject revision parameters from the side (e.g. read from standard input). Fortunately, the nature of this postprocessing is not affected by revision parameters; they are affected only by flags. So it is Ok to do add_object() after the it returns. This splits out the code that deals with the revision parameter out of the main loop of setup_revisions(), so that we can later call it from elsewhere after it returns. Signed-off-by: Junio C Hamano <>
2006-08-28Add --relative-date option to the revision interfaceJonas Fonseca
Exposes the infrastructure from 9a8e35e98793af086f05d1ca9643052df9b44a74. Signed-off-by: Jonas Fonseca <> Signed-off-by: Junio C Hamano <>
2006-08-23Convert memcpy(a,b,20) to hashcpy(a,b).Shawn Pearce
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2006-08-09check return value from diff_setup_done()Junio C Hamano
Signed-off-by: Junio C Hamano <>
2006-07-29Call setup_git_directory() earlyLinus Torvalds
Any git command that expects to work in a subdirectory of a project, and that reads the git config files (which is just about all of them) needs to make sure that it does the "setup_git_directory()" call before it tries to read the config file. This means, among other things, that we need to move the call out of "init_revisions()", and into the caller. This does the mostly trivial conversion to do that. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-07-13Remove TYPE_* constant macros and use object_type enums consistently.Linus Torvalds
This updates the type-enumeration constants introduced to reduce the memory footprint of "struct object" to match the type bits already used in the packfile format, by removing the former (i.e. TYPE_* constant macros) and using the latter (i.e. enum object_type) throughout the code for consistency. Eventually we can stop passing around the "type strings" entirely, and this will help - no confusion about two different integer enumeration. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-07-07git log -p --merge [[--] paths...]Junio C Hamano
This adds Linus's wish, "--merge" flag, which makes the above expand to a rough equivalent to: git log -p HEAD MERGE_HEAD ^$(git-merge-base HEAD MERGE_HEAD) \ -- $(git-ls-files -u [paths...] | cut -f2 | uniq) Signed-off-by: Junio C Hamano <>
2006-07-07Merge branch 'js/merge-base'Junio C Hamano
2006-07-05Merge branch 'th/diff'Junio C Hamano
* th/diff: builtin-diff: turn recursive on when defaulting to --patch format. t4013: note improvements brought by the new output code. t4013: add format-patch tests. format-patch: fix diff format option implementation combine-diff.c: type sanity. t4013 test updates for new output code. Fix some more diff options changes. Fix diff-tree -s log --raw: Don't descend into subdirectories by default diff-tree: Use ---\n as a message separator Print empty line between raw, stat, summary and patch t4013: add more tests around -c and --cc whatchanged: Default to DIFF_FORMAT_RAW Don't xcalloc() struct diffstat_t Add msg_sep to diff_options DIFF_FORMAT_RAW is not default anymore Set default diff output format after parsing command line Make --raw option available for all diff commands Merge with_raw, with_stat and summary variables to output_format t4013: add tests for diff/log family output options.
2006-07-04rev-list: free commit_list in ... handlerRene Scharfe
Johannes noticed the missing call to free_commit_list() in the patch from Santi to add ... support to rev-parse. Turns out I forgot it too in rev-list. This patch is against the next branch (3b1d06a). Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2006-07-03Merge branch 'master' into js/merge-baseJunio C Hamano
This is to pull in the object-hash clean-up from the master branch.
2006-07-02Fold get_merge_bases_clean() into get_merge_bases()Rene Scharfe
Change get_merge_bases() to be able to clean up after itself if needed by adding a cleanup parameter. We don't need to save the flags and restore them afterwards anymore; that was a leftover from before the flags were moved out of the range used in revision.c. clear_commit_marks() sets them to zero, which is enough. Signed-off-by: Rene Scharfe <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2006-07-02revision.c: fix "dense" under --remove-emptyLinus Torvalds
It had the wrong test for whether a commit was a merge. What it did was to say that a non-merge has exactly one parent (which sounds almost right), but the fact is, initial trees have no parent at all, but they're obviously not merges. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-07-02revision.c: --full-history fix.Linus Torvalds
With history simplification, we still show merges that are required to make the history _complete_, i.e. say that you had: a | b / \ c d | | and neither "a" nor "b" actually changed the file, but both "c" and "d" did: in this case we have to leave "b" around just because otherwise there would be no way to show the _relationship_, even if "b" itself doesn't actually change the tree in any way what-so-ever. It would make sense to make that further simplification if the "--parents" flag wasn't present. In that case the user is literally asking for a list of commits and is not interested in the relationship between them. This patch also fixes a real bug. Without this patch, the "--parents --full-history" combination (which you'd get if you do something like gitk --full-history Makefile or similar) will actually _drop_ merges where all children are identical. That's wrong in the --full-history case, because it means that the graph ends up missing lots of entries. In the process, this also should make git-rev-list --full-history Makefile give just the _true_ list of all commits that changed Makefile (and properly ignore merges that were identical in one parent), because now we're not asking for "--parent", so we don't need the unnecessary merge commits to keep the history together. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-07-02Add '...' operator for revisionsRene Scharfe
'A...B' is a shortcut for 'A B --not $(git-merge-base --all A B)'. This XOR-like operation is called symmetric difference in set theory. The symbol '...' has been chosen because it's rather similar to the existing '..' operator and the somewhat more natural caret ('^') is already taken. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2006-06-26DIFF_FORMAT_RAW is not default anymoreTimo Hirvonen
diff_setup() used to initialize output_format to DIFF_FORMAT_RAW. Now the default is 0 (no output) so don't compare against DIFF_FORMAT_RAW to see if any diff format command line flags were given. Signed-off-by: Timo Hirvonen <> Signed-off-by: Junio C Hamano <>
2006-06-20Add "named object array" conceptLinus Torvalds
We've had this notion of a "object_list" for a long time, which eventually grew a "name" member because some users (notably git-rev-list) wanted to name each object as it is generated. That object_list is great for some things, but it isn't all that wonderful for others, and the "name" member is generally not used by everybody. This patch splits the users of the object_list array up into two: the traditional list users, who want the list-like format, and who don't actually use or want the name. And another class of users that really used the list as an extensible array, and generally wanted to name the objects. The patch is fairly straightforward, but it's also biggish. Most of it really just cleans things up: switching the revision parsing and listing over to the array makes things like the builtin-diff usage much simpler (we now see exactly how many members the array has, and we don't get the objects reversed from the order they were on the command line). One of the main reasons for doing this at all is that the malloc overhead of the simple object list was actually pretty high, and the array is just a lot denser. So this patch brings down memory usage by git-rev-list by just under 3% (on top of all the other memory use optimizations) on the mozilla archive. It does add more lines than it removes, and more importantly, it adds a whole new infrastructure for maintaining lists of objects, but on the other hand, the new dynamic array code is pretty obvious. The change to builtin-diff-tree.c shows a fairly good example of why an array interface is sometimes more natural, and just much simpler for everybody. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-06-18Some more memory leak avoidanceLinus Torvalds
This is really the dregs of my effort to not waste memory in git-rev-list, and makes barely one percent of a difference in the memory footprint, but hey, it's also a pretty small patch. It discards the parent lists and the commit buffer after the commit has been shown by git-rev-list (and "git log" - which already did the commit buffer part), and frees the commit list entry that was used by the revision walker. The big win would be to get rid of the "refs" pointer in the object structure (another 5%), because it's only used by fsck. That would require some pretty major surgery to fsck, though, so I'm timid and did the less interesting but much easier part instead. This (percentually) makes a bigger difference to "git log" and friends, since those are walking _just_ commits, and thus the list entries tend to be a bigger percentage of the memory use. But the "list all objects" case does improve too. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-06-18Shrink "struct object" a bitLinus Torvalds
This shrinks "struct object" by a small amount, by getting rid of the "struct type *" pointer and replacing it with a 3-bit bitfield instead. In addition, we merge the bitfields and the "flags" field, which incidentally should also remove a useless 4-byte padding from the object when in 64-bit mode. Now, our "struct object" is still too damn large, but it's now less obviously bloated, and of the remaining fields, only the "util" (which is not used by most things) is clearly something that should be eventually discarded. This shrinks the "git-rev-list --all" memory use by about 2.5% on the kernel archive (and, perhaps more importantly, on the larger mozilla archive). That may not sound like much, but I suspect it's more on a 64-bit platform. There are other remaining inefficiencies (the parent lists, for example, probably have horrible malloc overhead), but this was pretty obvious. Most of the patch is just changing the comparison of the "type" pointer from one of the constant string pointers to the appropriate new TYPE_xxx small integer constant. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-06-17gitweb.cgi history not shownLinus Torvalds
This does: - add a "rev.simplify_history" flag which defaults to on - it turns it off for "git whatchanged" (which thus now has real semantics outside of "git log") - it adds a command line flag ("--full-history") to turn it off for others (ie you can make "git log" and "gitk" etc get the semantics if you want to. Now, just as an example of _why_ you really really really want to simplify history by default, apply this patch, install it, and try these two command lines: gitk --full-history -- git.c gitk -- git.c and compare the output. So with this, you can also now do git whatchanged -p -- gitweb.cgi git log -p --full-history -- gitweb.cgi and it will show the old history of gitweb.cgi, even though it's not relevant to the _current_ state of the name "gitweb.cgi" NOTE NOTE NOTE! It will still actually simplify away merges that didn't change anything at all into either child. That creates these bogus strange discontinuities if you look at it with "gitk" (look at the --full-history gitk output for git.c, and you'll see a few strange cases). So the whole "--parent" thing ends up somewhat bogus with --full-history because of this, but I'm not sure it's worth even worrying about. I don't think you'd ever want to really use "--full-history" with the graphical representation, I just give it as an example exactly to show _why_ doing so would be insane. I think this is trivial enough and useful enough to be worth merging into the stable branch. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-05-31tree_entry(): new tree-walking helper functionLinus Torvalds
This adds a "tree_entry()" function that combines the common operation of doing a "tree_entry_extract()" + "update_tree_entry()". It also has a simplified calling convention, designed for simple loops that traverse over a whole tree: the arguments are pointers to the tree descriptor and a name_entry structure to fill in, and it returns a boolean "true" if there was an entry left to be gotten in the tree. This allows tree traversal with struct tree_desc desc; struct name_entry entry; desc.buf = tree->buffer; desc.size = tree->size; while (tree_entry(&desc, &entry) { ... use "entry.{path, sha1, mode, pathlen}" ... } which is not only shorter than writing it out in full, it's hopefully less error prone too. [ It's actually a tad faster too - we don't need to recalculate the entry pathlength in both extract and update, but need to do it only once. Also, some callers can avoid doing a "strlen()" on the result, since it's returned as part of the name_entry structure. However, by now we're talking just 1% speedup on "git-rev-list --objects --all", and we're definitely at the point where tree walking is no longer the issue any more. ] NOTE! Not everybody wants to use this new helper function, since some of the tree walkers very much on purpose do the descriptor update separately from the entry extraction. So the "extract + update" sequence still remains as the core sequence, this is just a simplified interface. We should probably add a silly two-line inline helper function for initializing the descriptor from the "struct tree" too, just to cut down on the noise from that common "desc" initializer. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-05-30Convert "mark_tree_uninteresting()" to raw tree walkerLinus Torvalds
Not very many users to go.. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>