kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Linus Torvalds	36f8d17445	Teach git-rev-list about non-commit objects 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.	20 years ago
Linus Torvalds	3c90f03d32	Prepare git-rev-list for tracking tag objects too 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.	20 years ago
Linus Torvalds	9b66ec0474	Add "--pretty=full" format that also shows committer. 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.	20 years ago
Linus Torvalds	9ce43d1c90	Ooh. Make git-rev-list --object associate a name with objects. 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.	20 years ago
Linus Torvalds	9de48752fe	git-rev-list: add option to list all objects (not just commits) 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.	20 years ago
Jon Seymour	5e749e259b	[PATCH] Fix for --merge-order, --max-age interaction issue 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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Jon Seymour	51b1e1713b	[PATCH] Prevent git-rev-list without --merge-order producing duplicates in 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 <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	3d958064e0	Avoid warning about function without return. Strangely, this warning only shows up when not compiling with "-O2", which is why I didn't see it originally.	20 years ago
Linus Torvalds	8b3a1e056f	git-rev-list: add "--bisect" flag to find the "halfway" point 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.	20 years ago
Petr Baudis	17ebe977d7	[PATCH] Tidy up some rev-list-related stuff 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 <pasky@ucw.cz> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
jon@blackcubes.dyndns.org	a3437b8c26	[PATCH] Modify git-rev-list to linearise the commit history in merge order. 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/t6000-rev-list.sh, 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 ./t6000-rev-list.sh 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 `337cb3fb8d`. 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 http://blackcubes.dyndns.org/epoch/. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	000182eacf	pretty_print_commit: add different formats 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.	20 years ago
Linus Torvalds	337cb3fb8d	git-rev-list: allow arbitrary head selections, use git-rev-tree syntax 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).	20 years ago
Linus Torvalds	3b42a63cb5	git-rev-list: split out commit limiting from main() too. Ok, now I'm happier.	20 years ago
Linus Torvalds	81f2bb1f54	git-rev-list: factor out the commit printing from "main()" 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.	20 years ago
Linus Torvalds	9d97aa6466	git-rev-list: add "--pretty" command line option 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.	20 years ago
Linus Torvalds	97658004c3	git-rev-list: add "--parents" command line flag It makes rev-list show the list of parents, the same way git-rev-tree does (but without the expense).	20 years ago
Linus Torvalds	8906300f65	git-rev-list: use proper lazy reachability analysis 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.	20 years ago
Linus Torvalds	a6f68d4767	git-rev-list: add "end" commit and "--header" flag 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.	20 years ago
Alexey Nezhdanov	667bb59b2d	[PATCH] cleanup of in-code names Fixes all in-code names that leaved during "big name change". Signed-off-by: Alexey Nezhdanov <snake@penza-gsm.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Kay Sievers	fcfda02bc7	[PATCH] control/limit output of git-rev-list 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 <kay.sievers@vrfy.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	3c249c9506	Add "get_sha1()" helper function. 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.	20 years ago
Daniel Barkalow	58e28af6a4	[PATCH] Allow multiple date-ordered lists 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 <barkalow@iabervon.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	64745109c4	Add "rev-list" program that uses the new time-based commit listing. This is probably what you'd want to see for "git log".	20 years ago

24 Commits (e4b5c7fff47d3a794249ea2da6b9ec4e33e157f3)