summaryrefslogtreecommitdiff
path: root/builtin-rev-list.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'lt/rev-list-interactive'Junio C Hamano2007-11-181-8/+8
|\ | | | | | | | | | | | | | | | | * lt/rev-list-interactive: Fix parent rewriting in --early-output revision walker: mini clean-up Enhance --early-output format Add "--early-output" log flag for interactive GUI use Simplify topo-sort logic
| * Fix parent rewriting in --early-outputLinus Torvalds2007-11-141-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We cannot tell a node that has been checked and found not to be interesting (which does not have the TREECHANGE flag) from a node that hasn't been checked if it is interesting or not, without relying on something else, such as object->parsed. But an object can get the "parsed" flag for other reasons. Which means that "TREECHANGE" has the wrong polarity. This changes the way how the path pruning logic marks an uninteresting commits. From now on, we consider a commit interesting by default, and explicitly mark the ones we decided to prune. The flag is renamed to "TREESAME". Then, this fixes the logic to show the early output with incomplete pruning. It basically says "a commit that has TREESAME set is kind-of-UNINTERESTING", but obviously in a different way than an outright UNINTERESTING commit. Until we parse and examine enough parents to determine if a commit becomes surely "kind-of-UNINTERESTING", we avoid rewriting the ancestry so that later rounds can fix things up. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * revision walker: mini clean-upLinus Torvalds2007-11-051-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the unnecessary indirection of "revs->prune_fn", since that function is always the same one (or NULL), and there is in fact not even an abstraction reason to make it a function (i.e. its not called from some other file and doesn't allow us to keep the function itself static or anything like that). It then just replaces it with a bit that says "prune or not", and if not pruning, every commit gets TREECHANGE. That in turn means that - if (!revs->prune_fn || (flags & TREECHANGE)) - if (revs->prune_fn && !(flags & TREECHANGE)) just become - if (flags & TREECHANGE) - if (!(flags & TREECHANGE)) respectively. Together with adding the "single_parent()" helper function, the "complex" conditional now becomes if (!(flags & TREECHANGE) && rev->dense && single_parent(commit)) continue; Also indirection of "revs->dense" checking is thrown away the same way, because TREECHANGE bit is set appropriately now. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list: Introduce --quiet to avoid /dev/null redirectsShawn O. Pearce2007-11-111-4/+22
|/ | | | | | | | | | | | Some uses of git-rev-list are to run it with --objects to see if a range of objects between two or more commits is fully connected or not. In such a case the caller doesn't care about the actual object names or hash hints so formatting this data only for it to be dumped to /dev/null by a redirect is a waste of CPU time. If all the caller needs is the exit status then --quiet can be used to bypass the commit and object formatting. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* format-patch -s: add MIME encoding header if signer's name requires soJunio C Hamano2007-11-011-1/+2
| | | | | | | | | | | When the body of the commit log message contains a non-ASCII character, format-patch correctly emitted the encoding header to mark the resulting message as such. However, if the original message was fully ASCII, the command line switch "-s" was given to add a new sign-off, and the signer's name was not ASCII only, the resulting message would have contained non-ASCII character but was not marked as such. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-list: implement --bisect-allChristian Couder2007-10-261-14/+86
| | | | | | | | | | | This is Junio's patch with some stuff to make --bisect-all compatible with --bisect-vars. This option makes it possible to see all the potential bisection points. The best ones are displayed first. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Merge branch 'mv/unknown'Junio C Hamano2007-10-031-1/+2
|\ | | | | | | | | * mv/unknown: Don't use "<unknown>" for placeholders and suppress printing of empty user formats.
| * Don't use "<unknown>" for placeholders and suppress printing of empty user ↵Michal Vitecek2007-09-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | formats. This changes the interporate() to replace entries with NULL values by the empty string, and uses it to interpolate missing fields in custom format output used in git-log and friends. It is most useful to avoid <unknown> output from %b format for a commit log message that lack any body text. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ph/strbuf'Junio C Hamano2007-10-031-7/+6
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ph/strbuf: (44 commits) Make read_patch_file work on a strbuf. strbuf_read_file enhancement, and use it. strbuf change: be sure ->buf is never ever NULL. double free in builtin-update-index.c Clean up stripspace a bit, use strbuf even more. Add strbuf_read_file(). rerere: Fix use of an empty strbuf.buf Small cache_tree_write refactor. Make builtin-rerere use of strbuf nicer and more efficient. Add strbuf_cmp. strbuf_setlen(): do not barf on setting length of an empty buffer to 0 sq_quote_argv and add_to_string rework with strbuf's. Full rework of quote_c_style and write_name_quoted. Rework unquote_c_style to work on a strbuf. strbuf API additions and enhancements. nfv?asprintf are broken without va_copy, workaround them. Fix the expansion pattern of the pseudo-static path buffer. builtin-for-each-ref.c::copy_name() - do not overstep the buffer. builtin-apply.c: fix a tiny leak introduced during xmemdupz() conversion. Use xmemdupz() in many places. ...
| * Merge branch 'master' into ph/strbufJunio C Hamano2007-09-181-61/+72
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * master: (94 commits) Fixed update-hook example allow-users format. Documentation/git-svn: updated design philosophy notes t/t4014: test "am -3" with mode-only change. git-commit.sh: Shell script cleanup preserve executable bits in zip archives Fix lapsus in builtin-apply.c git-push: documentation and tests for pushing only branches git-svnimport: Use separate arguments in the pipe for git-rev-parse contrib/fast-import: add perl version of simple example contrib/fast-import: add simple shell example rev-list --bisect: Bisection "distance" clean up. rev-list --bisect: Move some bisection code into best_bisection. rev-list --bisect: Move finding bisection into do_find_bisection. Document ls-files --with-tree=<tree-ish> git-commit: partial commit of paths only removed from the index git-commit: Allow partial commit of file removal. send-email: make message-id generation a bit more robust git-apply: fix whitespace stripping git-gui: Disable native platform text selection in "lists" apply --index-info: fall back to current index for mode changes ...
| * | Rework pretty_print_commit to use strbufs instead of custom buffers.Pierre Habouzit2007-09-101-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also remove the "len" parameter, as: (1) it was used as a max boundary, and every caller used ~0u (2) we check for final NUL no matter what, so it doesn't help for speed. As a result most of the pp_* function takes 3 arguments less, and we need a lot less local variables, this makes the code way more readable, and easier to extend if needed. This patch also fixes some spacing and cosmetic issues. This patch also fixes (as a side effect) a memory leak intoruced in builtin-archive.c at commit df4a394f (fmt was xmalloc'ed and not free'd) Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | rev-list --bisect: Fix best == NULL case.Christian Couder2007-09-201-3/+3
| |/ |/| | | | | | | | | | | | | Earlier commit ce0cbad77 broke rev-list --bisect to cause it segfault when the resulting set is empty. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list --bisect: Bisection "distance" clean up.Christian Couder2007-09-181-11/+7
| | | | | | | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list --bisect: Move some bisection code into best_bisection.Christian Couder2007-09-181-17/+26
| | | | | | | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | rev-list --bisect: Move finding bisection into do_find_bisection.Christian Couder2007-09-181-42/+48
|/ | | | | | | This factorises some code and make a big function smaller. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2007-07-311-1/+1
|\ | | | | | | | | * maint: rev-list --bisect: fix allocation of "int*" instead of "int".
| * rev-list --bisect: fix allocation of "int*" instead of "int".Christian Couder2007-07-311-1/+1
| | | | | | | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Revert 88494423 (removal of duplicate parents in the output codepath)Junio C Hamano2007-07-081-13/+1
| | | | | | | | | | | | | | Now this is not needed, as we rewrite the parent list in the commit object itself. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Don't fflush(stdout) when it's not helpfulTheodore Ts'o2007-06-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch arose from a discussion started by Jim Meyering's patch whose intention was to provide better diagnostics for failed writes. Linus proposed a better way to do things, which also had the added benefit that adding a fflush() to git-log-* operations and incremental git-blame operations could improve interactive respose time feel, at the cost of making things a bit slower when we aren't piping the output to a downstream program. This patch skips the fflush() calls when stdout is a regular file, or if the environment variable GIT_FLUSH is set to "0". This latter can speed up a command such as: GIT_FLUSH=0 strace -c -f -e write time git-rev-list HEAD | wc -l a tiny amount. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Lift 16kB limit of log message outputJunio C Hamano2007-06-131-3/+5
|/ | | | | | | | | | | | | | | | | | | | | Traditionally we had 16kB limit when formatting log messages for output, because it was easier to arrange for the caller to have a reasonably big buffer and pass it down without ever worrying about reallocating. This changes the calling convention of pretty_print_commit() to lift this limit. Instead of the buffer and remaining length, it now takes a pointer to the pointer that points at the allocated buffer, and another pointer to the location that stores the allocated length, and reallocates the buffer as necessary. To support the user format, the error return of interpolate() needed to be changed. It used to return a bool telling "Ok the result fits", or "Sorry, I had to truncate it". Now it returns 0 on success, and returns the size of the buffer it wants in order to fit the whole result. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add --date={local,relative,default}Junio C Hamano2007-04-251-1/+1
| | | | | | | | | | | This adds --date={local,relative,default} option to log family of commands, to allow displaying timestamps in user's local timezone, relative time, or the default format. Existing --relative-date option is a synonym of --date=relative; we could probably deprecate it in the long run. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make sure quickfetch is not fooled with a previous, incomplete fetch.Junio C Hamano2007-04-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates git-rev-list --objects to be a bit more careful when listing a blob object to make sure the blob actually exists, and uses it to make sure the quick-fetch optimization we introduced earlier is not fooled by a previous incomplete fetch. The quick-fetch optimization works by running this command: git rev-list --objects <<commit-list>> --not --all where <<commit-list>> is a list of commits that we are going to fetch from the other side. If there is any object missing to complete the <<commit-list>>, the rev-list would fail and die (say, the commit was in our repository, but its tree wasn't -- then it will barf while trying to list the blobs the tree contains because it cannot read that tree). Usually we do not have the objects (otherwise why would we fetching?), but in one important special case we do: when the remote repository is used as an alternate object store (i.e. pointed by .git/objects/info/alternates). We could check .git/objects/info/alternates to see if the remote we are interacting with is one of them (or is used as an alternate, recursively, by one of them), but that check is more cumbersome than it is worth. The above check however did not catch missing blob, because object listing code did not read nor check blob objects, knowing that blobs do not contain any further references to other objects. This commit fixes it with practically unmeasurable overhead. I've benched this with git rev-list --objects --all >/dev/null in the kernel repository, with three different implementations of the "check-blob". - Checking with has_sha1_file() has negligible (unmeasurable) performance penalty. - Checking with sha1_object_info() makes it somewhat slower, perhaps by 5%. - Checking with read_sha1_file() to cause a fully re-validation is prohibitively expensive (about 4 times as much runtime). In my original patch, I had this as a command line option, but the overhead is small enough that it is not really worth it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'maint'Junio C Hamano2007-04-051-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Fix lseek(2) calls with args 2 and 3 swapped Honor -p<n> when applying git diffs Fix dependency of common-cmds.h Fix renaming branch without config file DESTDIR support for git/contrib/emacs gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches Document --left-right option to rev-list. Revert "builtin-archive: use RUN_SETUP" rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email. rerere: make sorting really stable. Fix t4200-rerere for white-space from "wc -l"
| * Document --left-right option to rev-list.Brian Gernhardt2007-04-051-0/+1
| | | | | | | | | | | | Explanation is paraphrased from "577ed5c... rev-list --left-right" Signed-off-by: Junio C Hamano <junkio@cox.net>
* | make the previous optimization work also on path-limited rev-list --bisectJunio C Hamano2007-03-231-98/+151
| | | | | | | | | | | | | | | | The trick is to give a child commit that is not tree-changing the same depth as its parent, so that the depth is propagated properly along strand of pearls. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | rev-list --bisect: Fix "halfway" optimization.Junio C Hamano2007-03-231-6/+26
| | | | | | | | | | | | | | | | | | If you have 5 commits in the set, commits that reach 2 or 3 commits are at halfway. If you have 6 commits, only commits that reach exactly 3 commits are at halfway. The earlier one is completely botched the math. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'master' into jc/bisectJunio C Hamano2007-03-231-2/+2
|\ \ | |/ | | | | | | This is to merge in the fix for path-limited bisection from the 'master' branch.
| * Fix path-limited "rev-list --bisect" termination condition.Junio C Hamano2007-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a path-limited bisection, when the $bad commit is not changing the limited path, and the number of suspects is 1, the code miscounted and returned $bad from find_bisection(), which is not marked with TREECHANGE. This is of course filtered by the output routine, resulting in an empty output, in turn causing git-bisect driver to say "$bad was both good and bad". Illustration. Suppose you have these four commits, and only C changes path P. You know D is bad and A is good. A---B---C*--D git-bisect driver runs this to find a bisection point: $ git rev-list --bisect A..D -- P which calls find_bisection() with B, C and D. The set of commits that is given to this function is the same set of commits as rev-list without --bisect option and pathspec returns. Among them, only C is marked with TREECHANGE. Let's call the set of commits given to find_bisection() that are marked with TREECHANGE (or all of them if no path limiter is in effect) "the bisect set". In the above example, the size of the bisect set is 1 (contains only "C"). For each commit in its input, find_bisection() computes the number of commits it can reach in the bisect set. For a commit in the bisect set, this number includes itself, so the number is 1 or more. This number is called "depth", and computed by count_distance() function. When you have a bisect set of N commits, and a commit has depth D, how good is your bisection if you returned that commit? How good this bisection is can be measured by how many commits are effectively tested "together" by testing one commit. Currently you have (N-1) untested commits (the tip of the bisect set, although it is included in the bisect set, is already known to be bad). If the commit with depth D turns out to be bad, then your next bisect set will have D commits and you will have (D-1) untested commits left, which means you tested (N-1)-(D-1) = (N-D) commits with this bisection. If it turns out to be good, then your next bisect set will have (N-D) commits, and you will have (N-D-1) untested commits left, which means you tested (N-1)-(N-D-1) = D commits with this bisection. Therefore, the goodness of this bisection is is min(N-D, D), and find_bisection() function tries to find a commit that maximizes this, by initializing "closest" variable to 0 and whenever a commit with the goodness that is larger than the current "closest" is found, that commit and its goodness are remembered by updating "closest" variable. The "the commit with the best goodness so far" is kept in "best" variable, and is initialized to a commit that happens to be at the beginning of the list of commits given to this function (which may or may not be in the bisect set when path-limit is in use). However, when N is 1, then the sole tree-changing commit has depth of 1, and min(N-D, D) evaluates to 0. This is not larger than the initial value of "closest", and the "so far the best one" commit is never replaced in the loop. When path-limit is not in use, this is not a problem, as any commit in the input set is tree-changing. But when path-limit is in use, and when the starting "bad" commit does not change the specified path, it is not correct to return it. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-rev-list --bisect: optimizationJunio C Hamano2007-03-221-2/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This improves the performance of revision bisection. The idea is to avoid rather expensive count_distance() function, which counts the number of commits that are reachable from any given commit (including itself) in the set. When a commit has only one relevant parent commit, the number of commits the commit can reach is exactly the number of commits that the parent can reach plus one; instead of running count_distance() on commits that are on straight single strand of pearls, we can just add one to the parents' count. On the other hand, for a merge commit, because the commits reachable from one parent can be reachable from another parent, you cannot just add the parents' counts up plus one for the commit itself; that would overcount ancestors that are reachable from more than one parents. The algorithm used in the patch runs count_distance() on merge commits, and uses the util field of commit objects to remember them. After that, the number of commits reachable from each of the remaining commits is counted by finding a commit whose count is not yet known but the count for its (sole) parent is known, and adding one to the parent's count, until we assign numbers to everybody. Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. The performance to bisect between v1.0.0 and v1.5.0 in git.git repository was improved by saying good and bad in turns from 3.68 seconds down to 1.26 seconds. Bisecting the kernel between v2.6.18 and v2.6.20 was sped up from 21.84 seconds down to 4.22 seconds. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-rev-list: add --bisect-vars option.Junio C Hamano2007-03-221-6/+48
|/ | | | | | | | | | | | | | | | | | | This adds --bisect-vars option to rev-list. The output is suitable for `eval` in shell and defines five variables: - bisect_rev is the next revision to test. - bisect_nr is the expected number of commits to test after bisect_rev is tested. - bisect_good is the expected number of commits to test if bisect_rev turns out to be good. - bisect_bad is the expected number of commits to test if bisect_rev turns out to be bad. - bisect_all is the number of commits we are bisecting right now. The documentation text was partly stolen from Johannes Schindelin's patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Read the config in rev-listFredrik Kuivinen2007-02-181-0/+1
| | | | | | | | Otherwise "git rev-list --header HEAD" will not do the right thing if i18n.commitencoding is set. Signed-off-by: Fredrik Kuivinen <frekui@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Teach all of log family --left-right output.Junio C Hamano2006-12-171-6/+1
| | | | | | | | | | This makes reviewing git log --left-right --merge --no-merges -p a lot more pleasant. Signed-off-by: Junio C Hamano <junkio@cox.net>
* rev-list --left-rightJunio C Hamano2006-12-171-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <junkio@cox.net>
* git log: Unify header_filter and message_filter into one.Junio C Hamano2006-09-201-3/+1
| | | | | | | | | | | | | | | | | | | | 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 <junkio@cox.net>
* rev-list: fix segfault with --{author,committer,grep}Jeff King2006-09-201-1/+3
| | | | | | | We need to save the commit buffer if we're going to match against it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* pack-objects: further work on internal rev-list logic.Junio C Hamano2006-09-071-30/+6
| | | | | | | | | | This teaches the internal rev-list logic to understand options that are needed for pack handling: --all, --unpacked, and --thin. It also moves two functions from builtin-rev-list to list-objects so that the two programs can share more code. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Separate object listing routines out of rev-listJunio C Hamano2006-09-071-97/+13
| | | | | | | | Create a separate file, list-objects.c, and move object listing routines from rev-list to it. The next round will use it in pack-objects directly. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Teach rev-list an option to read revs from the standard input.Junio C Hamano2006-09-051-0/+25
| | | | | | | | | | | | | When --stdin option is given, in addition to the <rev>s listed on the command line, the command can read one rev parameter per line from the standard input. The list of revs ends at the first empty line or EOF. Note that you still have to give all the flags from the command line; only rev arguments (including A..B, A...B, and A^@ notations) can be give from the standard input. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Replace uses of strdup with xstrdup.Shawn Pearce2006-09-021-2/+2
| | | | | | | | | | | | | | | | Like xmalloc and xrealloc xstrdup dies with a useful message if the native strdup() implementation returns NULL rather than a valid pointer. I just tried to use xstrdup in new code and found it to be missing. However I expected it to be present as xmalloc and xrealloc are already commonly used throughout the code. [jc: removed the part that deals with last_XXX, which I am finding more and more dubious these days.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add --relative-date option to the revision interfaceJonas Fonseca2006-08-281-1/+1
| | | | | | | Exposes the infrastructure from 9a8e35e98793af086f05d1ca9643052df9b44a74. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* free(NULL) is perfectly valid.Junio C Hamano2006-08-271-4/+2
| | | | | | | Jonas noticed some places say "if (X) free(X)" which is totally unnecessary. Signed-off-by: Junio C Hamano <junkio@cox.net>
* remove unnecessary initializationsDavid Rientjes2006-08-151-3/+3
| | | | | | | | [jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Call setup_git_directory() much earlierLinus Torvalds2006-07-291-2/+2
| | | | | | | | | This changes the calling convention of built-in commands and passes the "prefix" (i.e. pathname of $PWD relative to the project root level) down to them. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Call setup_git_directory() earlyLinus Torvalds2006-07-281-1/+1
| | | | | | | | | | | | | | | 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Remove TYPE_* constant macros and use object_type enums consistently.Linus Torvalds2006-07-121-3/+3
| | | | | | | | | | | | | | | 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add "named object array" conceptLinus Torvalds2006-06-191-31/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Some more memory leak avoidanceLinus Torvalds2006-06-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Shrink "struct object" a bitLinus Torvalds2006-06-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* rev-list: fix process_tree() conversion.Linus Torvalds2006-06-051-2/+2
| | | | | | | The tree-walking conversion of the "process_tree()" function broke packing by using an unrelated variable from outer scope. Signed-off-by: Junio C Hamano <junkio@cox.net>
* tree_entry(): new tree-walking helper functionLinus Torvalds2006-05-301-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
View Lorry Controller Status