- 30 6月, 2005 2 次提交
-
-
由 Linus 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.
-
由 Linus 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.
-
- 27 6月, 2005 2 次提交
-
-
由 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.
-
由 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.
-
- 25 6月, 2005 1 次提交
-
-
由 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.
-
- 20 6月, 2005 2 次提交
-
-
由 Jon 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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jon Seymour 提交于
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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 19 6月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Strangely, this warning only shows up when not compiling with "-O2", which is why I didn't see it originally.
-
- 18 6月, 2005 1 次提交
-
-
由 Linus 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.
-
- 09 6月, 2005 1 次提交
-
-
由 Petr 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: NPetr Baudis <pasky@ucw.cz> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 6月, 2005 1 次提交
-
-
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 337cb3fb. 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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 06 6月, 2005 1 次提交
-
-
由 Linus 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.
-
- 05 6月, 2005 1 次提交
-
-
由 Linus 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).
-
- 03 6月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
Ok, now I'm happier.
-
由 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.
-
- 01 6月, 2005 1 次提交
-
-
由 Linus 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.
-
- 31 5月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
It makes rev-list show the list of parents, the same way git-rev-tree does (but without the expense).
-
由 Linus 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.
-
- 26 5月, 2005 1 次提交
-
-
由 Linus 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.
-
- 20 5月, 2005 1 次提交
-
-
由 Alexey Nezhdanov 提交于
Fixes all in-code names that leaved during "big name change". Signed-off-by: NAlexey Nezhdanov <snake@penza-gsm.ru> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 5月, 2005 1 次提交
-
-
由 Kay 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: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 02 5月, 2005 1 次提交
-
-
由 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.
-
- 24 4月, 2005 2 次提交
-
-
由 Daniel 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: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
This is probably what you'd want to see for "git log".
-