- 10 8月, 2005 2 次提交
-
-
由 Junio C Hamano 提交于
This introduces --pretty=oneline to git-rev-tree and git-rev-list commands to show only the first line of the commit message, without frills. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
As requested by Junio (who suggested --single-parents-only, but this could forget a no-parent root). Also, adds a few missing options to the usage string. Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 05 8月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
The King Penguin says: Now, for extra bonus points, maybe you should make "git-rev-list" also understand the "rev..rev" format (which you can't do with just the get_sha1() interface, since it expands into more). The faithful servant makes it so. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 30 7月, 2005 2 次提交
-
-
由 Petr Baudis 提交于
Support for completely OpenSSL-less builds. FSF considers distributing GPL binaries with OpenSSL linked in as a legal problem so this is trouble e.g. for Debian, or some people might not want to install OpenSSL anyway. If you make NO_OPENSSL=1 you get completely OpenSSL-less build, disabling --merge-order and using Mozilla's SHA1 implementation. Ported from Cogito. Signed-off-by: NPetr Baudis <pasky@ucw.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
This corner-case was triggered by a kernel commit that was not in date order, due to a misconfigured time zone that made the commit appear three hours older than it was. That caused git-rev-list to traverse the commit tree in a non-obvious order, and made it parse several of the _parents_ of the misplaced commit before it actually parsed the commit itself. That's fine, but it meant that the grandparents of the commit didn't get marked uninteresting, because they had been reached through an "interesting" branch. The reason was that "mark_parents_uninteresting()" (which is supposed to mark all existing parents as being uninteresting - duh) didn't actually traverse more than one level down the parent chain. NORMALLY this is fine, since with the date-based traversal order, grandparents won't ever even have been looked at before their parents (so traversing the chain down isn't needed, because the next time around when we pick out the parent we'll mark _its_ parents uninteresting), but since we'd gotten out of order, we'd already seen the parent and thus never got around to mark the grandparents. Anyway, the fix is simple. Just traverse parent chains recursively. Normally the chain won't even exist (since the parent hasn't been parsed yet), so this is not actually going to trigger except in this strange corner-case. Add a comment to the simple one-liner, since this was a bit subtle, and I had to really think things through to understand how it could happen. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 7月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
The *_usage strings should not start with "usage: ", since the usage() function gives its own. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 7月, 2005 1 次提交
-
-
由 Linus 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.
-
- 12 7月, 2005 1 次提交
-
-
由 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: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 11 7月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
We still want the "top-most" uninteresting object to exist, so that we know that we have reached it.
-
- 07 7月, 2005 8 次提交
-
-
由 Jon Seymour 提交于
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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus 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.
-
由 Linus Torvalds 提交于
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.
-
由 Jon 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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
-
由 Linus Torvalds 提交于
..and move the DUPCHECK to rev-list.c since both the merge-order and the upcoming topo-sort get confused by dups.
-
由 Linus Torvalds 提交于
Jon wants the commits in a different order for merge-order.
-
由 Linus Torvalds 提交于
Same argument order, same return type. This allows us to use a function pointer to choose one over the other.
-
- 06 7月, 2005 1 次提交
-
-
由 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.
-
- 05 7月, 2005 2 次提交
-
-
由 Linus Torvalds 提交于
We didn't sort the refs by date, so if you had multiple refs, the end result would not be properly sorted.
-
由 Linus Torvalds 提交于
We'd rather get the revisions in a slow but timely manner than have to wait for them.
-
- 04 7月, 2005 3 次提交
-
-
由 Linus Torvalds 提交于
More infrastructure to do efficient incremental packs.
-
由 Linus Torvalds 提交于
And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
-
由 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.
-
- 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 1 次提交
-
-
由 Linus Torvalds 提交于
It makes rev-list show the list of parents, the same way git-rev-tree does (but without the expense).
-