path: root/rev-list.c
AgeCommit message (Collapse)Author
2005-07-23Be more aggressive about marking trees uninterestingLinus Torvalds
We'll mark all the trees at the edges (as deep as we had to go to realize that we have all the commits needed) as uninteresting. Otherwise we'll occasionally list a lot of objects that were actually available at the edge in a commit that we just never ended up parsing because we could determine early that we had all relevant commits. NOTE! The object listing is still just a _heuristic_. It's guaranteed to list a superset of the actual new objects, but there might be the occasional old object in the list, just because the commit that referenced it was much further back in the history. For example, let's say that a recent commit is a revert of part of the tree to much older state: since we didn't walk _that_ far back in the commit history tree to list the commits necessary, git-rev-tree will never have marked the old objects uninteresting, and we'll end up listing them as "new". That's ok.
2005-07-11[PATCH] Dereference tag repeatedly until we get a non-tag.Junio C Hamano
When we allow a tag object in place of a commit object, we only dereferenced the given tag once, which causes a tag that points at a tag that points at a commit to be rejected. Instead, dereference tag repeatedly until we get a non-tag. This patch makes change to two functions: - commit.c::lookup_commit_reference() is used by merge-base, rev-tree and rev-parse to convert user supplied SHA1 to that of a commit. - rev-list uses its own get_commit_reference() to do the same. Dereferencing tags this way helps both of these uses. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-07-10git-rev-list: allow missing objects when the parent is marked UNINTERESTINGLinus Torvalds
We still want the "top-most" uninteresting object to exist, so that we know that we have reached it.
2005-07-07[PATCH] Ensure list insertion method does not depend on position of ↵Jon Seymour
--merge-order argument This change ensures that git-rev-list --merge-order produces the same result irrespective of what position the --merge-order argument appears in the argument list. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-07-06git-rev-list: remove the DUPCHECK logic, use SEEN insteadLinus Torvalds
That's what we should have done in the first place, since it not only avoids another unnecessary flag, it also protects the commits from showing up as duplicates later when they show up as parents of another commit (in the pop_most_recent_commit() path). This will hopefully also fix --topo-sort.
2005-07-06Make sure we generate the whole commit list before trying to sort it ↵Linus Torvalds
topologically This was my cherry-pickng merge bug. But topo-order still shows strange behaviour with multiple heads, so keep gitk using --merge-order for now.
2005-07-06[PATCH] Tidy up - slight simplification of rev-list.cJon Seymour
This patch implements a small tidy up of rev-list.c to reduce (but not eliminate) the amount of ugliness associated with the merge_order flag. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-07-06Add "--topo-order" flag to use new topological sortLinus Torvalds
2005-07-06Remove insane overlapping bit ranges from epoch.cLinus Torvalds
..and move the DUPCHECK to rev-list.c since both the merge-order and the upcoming topo-sort get confused by dups.
2005-07-06Clean up commit insertion in git-rev-listLinus Torvalds
Jon wants the commits in a different order for merge-order.
2005-07-06Make "insert_by_date()" match "commit_list_insert()"Linus Torvalds
Same argument order, same return type. This allows us to use a function pointer to choose one over the other.
2005-07-05Remove unnecessary usage of strncmp() in git-rev-list arg parsing.Linus Torvalds
Not only is it unnecessary, it incorrectly allows extraneous characters at the end of the argument. Junio noticed the --merge-order thing, and Jon points out that if we fix that one, we should fix --show-breaks too.
2005-07-04git-rev-list: make sure the output is sorted by recencyLinus Torvalds
We didn't sort the refs by date, so if you had multiple refs, the end result would not be properly sorted.
2005-07-04Make rev-list flush the stdio buffers after each rev.Linus Torvalds
We'd rather get the revisions in a slow but timely manner than have to wait for them.
2005-07-03"git rev-list --unpacked" shows only unpacked commitsLinus Torvalds
More infrastructure to do efficient incremental packs.
2005-07-03Add "--all" flag to rev-parse that shows all refsLinus Torvalds
And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
2005-07-03Fix sparse warnings.Linus Torvalds
Mainly making a lot of local functions and variables be marked "static", but there was a "zero as NULL" warning in there too.
2005-06-29Teach git-rev-list about non-commit objectsLinus Torvalds
Now you can give git-rev-list tags, trees and blobs, and it will do the proper reachability for them all. Knock wood. Of course, you need the "--objects" flag to do anything but plain commits.
2005-06-29Prepare git-rev-list for tracking tag objects tooLinus Torvalds
We want to be able to just say "give a difference between these objects", rather than limiting it to commits only. This isn't there yet, but it sets things up to be a bit easier.
2005-06-27Add "--pretty=full" format that also shows committer.Linus Torvalds
Also move the common implementation of parsing the --pretty argument format into commit.c rather than having duplicates in diff-tree.c and rev-list.c.
2005-06-26Ooh. Make git-rev-list --object associate a name with objects.Linus Torvalds
The name isn't unique, it's just the first name that object is reached through, so it's really nothing more than a hint.
2005-06-25git-rev-list: add option to list all objects (not just commits)Linus Torvalds
When you do git-rev-list --objects $(git-rev-parse HEAD^..HEAD) it now lists not only the "commit difference" between the parent of HEAD and HEAD itself (which is normally just the parent, but in the case of a merge will be all the newly merged commits), but also all the new tree and blob objects that weren't in the original. NOTE! It doesn't walk all the way to the root, so it doesn't do a full object search in the full old history. Instead, it will only look as far back in the history as it needs to resolve the commits. Thus, if the commit reverts a blob (or tree) back to a state much further back in history, we may end up listing some blobs (or trees) as "new" even though they exist further back. Regardless, the list of objects will be a superset (usually exact) list of objects needed to go from the beginning commit to ending commit. As a particularly obvious special case, git-rev-list --objects HEAD will end up listing every single object that is reachable from the HEAD commit. Side note: the objects are sorted by "recency", with commits first.
2005-06-20[PATCH] Fix for --merge-order, --max-age interaction issueJon Seymour
This patch fixes a problem reported by Paul Mackerras regarding the interaction of the --merge-order and --max-age switches of git-rev-list. This patch applies to the current Linus HEAD. A cleaner fix for the same problem in my current HEAD will follow later. With this change, --merge-order produces the same result as no --merge-order on the linux-2.6 git repository, to wit: $> git-rev-list --max-age=1116330140 bcfff0b471a60df350338bcd727fc9b8a6aa54b2 | wc -l 655 $> git-rev-list --merge-order --max-age=1116330140 bcfff0b471a60df350338bcd727fc9b8a6aa54b2 | wc -l 655 Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-20[PATCH] Prevent git-rev-list without --merge-order producing duplicates in ↵Jon Seymour
output If b is reachable from a, then: git-rev-list a b argument would print one of the commits twice. This patch fixes that problem. A previous problem fixed it for the --merge-order switch. Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-19Avoid warning about function without return.Linus Torvalds
Strangely, this warning only shows up when not compiling with "-O2", which is why I didn't see it originally.
2005-06-18git-rev-list: add "--bisect" flag to find the "halfway" pointLinus Torvalds
This is useful for doing binary searching for problems. You start with a known good and known bad point, and you then test the "halfway" point in between: git-rev-list --bisect bad ^good and you test that. If that one tests good, you now still have a known bad case, but two known good points, and you can bisect again: git-rev-list --bisect bad ^good1 ^good2 and test that point. If that point is bad, you now use that as your known-bad starting point: git-rev-list --bisect newbad ^good1 ^good2 and basically at every iteration you shrink your list of commits by half: you're binary searching for the point where the troubles started, even though there isn't a nice linear ordering.
2005-06-08[PATCH] Tidy up some rev-list-related stuffPetr Baudis
This patch tidies up the git-rev-list documentation and epoch.c, which are in severe clash with the unwritten coding style now, and quite unreadable. It also fixes up compile failures with older compilers due to variable declarations after code. The patch mostly wraps lines before or on the 80th column, removes plenty of superfluous empty lines and changes comments from // to /* */. Signed-off-by: Petr Baudis <> Signed-off-by: Linus Torvalds <>
2005-06-06[PATCH] Modify git-rev-list to linearise the commit history in merge
This patch linearises the GIT commit history graph into merge order which is defined by invariants specified in Documentation/git-rev-list.txt. The linearisation produced by this patch is superior in an objective sense to that produced by the existing git-rev-list implementation in that the linearisation produced is guaranteed to have the minimum number of discontinuities, where a discontinuity is defined as an adjacent pair of commits in the output list which are not related in a direct child-parent relationship. With this patch a graph like this: a4 --- | \ \ | b4 | |/ | | a3 | | | | | a2 | | | | c3 | | | | | c2 | b3 | | | /| | b2 | | | c1 | | / | b1 a1 | | | a0 | | / root Sorts like this: = a4 | c3 | c2 | c1 ^ b4 | b3 | b2 | b1 ^ a3 | a2 | a1 | a0 = root Instead of this: = a4 | c3 ^ b4 | a3 ^ c2 ^ b3 ^ a2 ^ b2 ^ c1 ^ a1 ^ b1 ^ a0 = root A test script, t/, includes a test which demonstrates that the linearisation produced by --merge-order has less discontinuities than the linearisation produced by git-rev-list without the --merge-order flag specified. To see this, do the following: cd t ./ cd trash cat actual-default-order cat actual-merge-order The existing behaviour of git-rev-list is preserved, by default. To obtain the modified behaviour, specify --merge-order or --merge-order --show-breaks on the command line. This version of the patch has been tested on the git repository and also on the linux-2.6 repository and has reasonable performance on both - ~50-100% slower than the original algorithm. This version of the patch has incorporated a functional equivalent of the Linus' output limiting algorithm into the merge-order algorithm itself. This operates per the notes associated with Linus' commit 337cb3fb8da45f10fe9a0c3cf571600f55ead2ce. This version has incorporated Linus' feedback regarding proposed changes to rev-list.c. (see: [PATCH] Factor out filtering in rev-list.c) This version has improved the way sort_first_epoch marks commits as uninteresting. For more details about this change, refer to Documentation/git-rev-list.txt and Signed-off-by: Jon Seymour <> Signed-off-by: Linus Torvalds <>
2005-06-05pretty_print_commit: add different formatsLinus Torvalds
You can ask to print out "raw" format (full headers, full body), "medium" format (author and date, full body) or "short" format (author only, condensed body). Use "git-rev-list --pretty=short HEAD | less -S" for an example.
2005-06-04git-rev-list: allow arbitrary head selections, use git-rev-tree syntaxLinus Torvalds
This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).
2005-06-02git-rev-list: split out commit limiting from main() too.Linus Torvalds
Ok, now I'm happier.
2005-06-02git-rev-list: factor out the commit printing from "main()"Linus Torvalds
Functions that do many things are bad. We should basically just parse the arguments in main(). We're not quite there yet, but it's a step in the right direction.
2005-06-01git-rev-list: add "--pretty" command line optionLinus Torvalds
That pretty-prints the resulting commit messages, so git-rev-list --pretty HEAD v2.6.12-rc5 | less -S basically ends up being a log of the changes between -rc5 and current head. It uses the pretty-printing helper function I just extracted from diff-tree.c.
2005-05-31git-rev-list: add "--parents" command line flagLinus Torvalds
It makes rev-list show the list of parents, the same way git-rev-tree does (but without the expense).
2005-05-31git-rev-list: use proper lazy reachability analysisLinus Torvalds
This mean sthat you can give a beginning/end pair to git-rev-list, and it will show all entries that are reachable from the beginning but not the end. For example git-rev-list v2.6.12-rc5 v2.6.12-rc4 shows all commits that are in -rc5 but are not in -rc4.
2005-05-26git-rev-list: add "end" commit and "--header" flagLinus Torvalds
The "end" commit is just faking it right now, it's sorting things purely by date, so this is _not_ a reachability analysis. Some day. The "--header" flag causes the commit message to be printed out, with a NUL character separator after it for parseability. This allows you to do things like use "grep -z" to grep for certain authors etc.
2005-05-19[PATCH] cleanup of in-code namesAlexey Nezhdanov
Fixes all in-code names that leaved during "big name change". Signed-off-by: Alexey Nezhdanov <> Signed-off-by: Linus Torvalds <>
2005-05-06[PATCH] control/limit output of git-rev-listKay Sievers
gitweb.cgi's default view is the log of the last day and git-rev-list can stop crawling the whole repo if we have all our data to display in the browser. Also the rss-feed query needs only the last 20 items. This will speeds up these queries dramatically. usage: rev-list [OPTION] commit-id --max-count=nr --max-age=epoch --min-age=epoch Signed-off-by: Kay Sievers <> Signed-off-by: Linus Torvalds <>
2005-05-01Add "get_sha1()" helper function.Linus Torvalds
This allows the programs to use various simplified versions of the SHA1 names, eg just say "HEAD" for the SHA1 pointed to by the .git/HEAD file etc. For example, this commit has been done with git-commit-tree $(git-write-tree) -p HEAD instead of the traditional "$(cat .git/HEAD)" syntax.
2005-04-24[PATCH] Allow multiple date-ordered listsDaniel Barkalow
Make pop_most_recent_commit() return the same objects multiple times, but only if called with different bits to mark. This is necessary to make merge-base work again. Signed-Off-By: Daniel Barkalow <> Signed-off-by: Linus Torvalds <>
2005-04-24Add "rev-list" program that uses the new time-based commit listing.Linus Torvalds
This is probably what you'd want to see for "git log".