- 27 8月, 2009 1 次提交
-
-
由 Lars Hjemli 提交于
Commit de435ac0 changed the behavior of --decorate from printing the full ref (e.g., "refs/heads/master") to a shorter, more human-readable version (e.g., just "master"). While this is nice for human readers, external tools using the output from "git log" may prefer the full version. This patch introduces an extension to --decorate to allow the caller to specify either the short or the full versions. Signed-off-by: NLars Hjemli <hjemli@gmail.com> Acked-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 8月, 2009 1 次提交
-
-
由 Adam Simpkins 提交于
Previously, graph_is_interesting() did not behave quite the same way as the code in get_revision(). As a result, it would sometimes think commits were uninteresting, even though get_revision() would return them. This resulted in incorrect lines in the graph output. This change creates a get_commit_action() function, which graph_is_interesting() and simplify_commit() both now use to determine if a commit will be shown. It is identical to the old simplify_commit() behavior, except that it never calls rewrite_parents(). This problem was reported by Santi Béjar. The following command would exhibit the problem before, but now works correctly: git log --graph --simplify-by-decoration --oneline v1.6.3.3 Previously git graph did not display the output for this command correctly between f29ac4f1 and 66996ecc, among other places. Signed-off-by: NAdam Simpkins <simpkins@facebook.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 8月, 2009 1 次提交
-
-
由 Lars Hjemli 提交于
Commit de435ac0 changed the behavior of --decorate from printing the full ref (e.g., "refs/heads/master") to a shorter, more human-readable version (e.g., just "master"). While this is nice for human readers, external tools using the output from "git log" may prefer the full version. This patch introduces an extension to --decorate to allow the caller to specify either the short or the full versions. Signed-off-by: NLars Hjemli <hjemli@gmail.com> Acked-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 7月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
For some reason, I ended up doing git show HEAD~5.. as an odd way of asking for a log. I realize I should just have used "git log", but at the same time it does make perfect conceptual sense. After all, you _could_ have done git show HEAD HEAD~1 HEAD~2 HEAD~3 HEAD~4 and saying "git show HEAD~5.." is pretty natural. It's not like "git show" only ever showed a single commit (or other object) before either! So conceptually, giving a commit range is a very sensible operation, even though you'd traditionally have used "git log" for that. However, doing that currently results in an error fatal: object ranges do not make sense when not walking revisions which admittedly _also_ makes perfect sense - from an internal git implementation standpoint in 'revision.c'. However, I think that asking to show a range makes sense to a user, while saying "object ranges no not make sense when not walking revisions" only makes sense to a git developer. So on the whole, of the two different "makes perfect sense" behaviors, I think I originally picked the wrong one. And quite frankly, I don't really see anybody actually _depending_ on that error case. So why not change it? So rather than error out, just turn that non-walking error case into a "silently turn on walking" instead. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
I do various statistics on git, and one of the things I look at is merges, because they are often interesting events to count ("how many merges vs how much 'real development'" kind of statistics). And you can do it with some fairly straightforward scripting, ie git rev-list --parents HEAD | grep ' .* ' | git diff-tree --always -s --pretty=oneline --stdin | less -S will do it. But I finally got irritated with the fact that we can skip merges with '--no-merges', but we can't do the trivial reverse operation. So this just adds a '--merges' flag that _only_ shows merges. Now you can do the above with just a git log --merges --pretty=oneline which is a lot simpler. It also means that we automatically get a lot of statistics for free, eg git shortlog -ns --merges does exactly what you'd want it to do. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
This simplifies the logic of rev_compare_tree() by removing a special case. It does so by turning the special case of finding a diff to be "all new files" into a more generic case of "all new" vs "all removed" vs "mixed changes", so now the code is actually more powerful and more generic, and the added symmetry actually makes it simpler too. This makes no changes to any existing behavior, but apart from the simplification it does make it possible to some day care about whether all changes were just deletions if we want to. Which we may well want to for merge handling. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 4月, 2009 1 次提交
-
-
由 Mike Ralphson 提交于
Signed-off-by: NMike Ralphson <mike@abacus.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 4月, 2009 2 次提交
-
-
由 Linus Torvalds 提交于
In particular, pushing the "path_name()" call _into_ the show() function would seem to allow - more clarity into who "owns" the name (ie now when we free the name in the show_object callback, it's because we generated it ourselves by calling path_name()) - not calling path_name() at all, either because we don't care about the name in the first place, or because we are actually happy walking the linked list of "struct name_path *" and the last component. Now, I didn't do that latter optimization, because it would require some more coding, but especially looking at "builtin-pack-objects.c", we really don't even want the whole pathname, we really would be better off with the list of path components. Why? We use that name for two things: - add_preferred_base_object(), which actually _wants_ to traverse the path, and now does it by looking for '/' characters! - for 'name_hash()', which only cares about the last 16 characters of a name, so again, generating the full name seems to be just unnecessary work. Anyway, so I didn't look any closer at those things, but it did convince me that the "show_object()" calling convention was crazy, and we're actually better off doing _less_ in list-objects.c, and giving people access to the internal data structures so that they can decide whether they want to generate a path-name or not. This patch does that, and then for people who did use the name (even if they might do something more clever in the future), it just does the straightforward "name = path_name(path, component); .. free(name);" thing. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
Here's a less trivial thing, and slightly more dubious one. I was looking at that "struct object_array objects", and wondering why we do that. I have honestly totally forgotten. Why not just call the "show()" function as we encounter the objects? Rather than add the objects to the object_array, and then at the very end going through the array and doing a 'show' on all, just do things more incrementally. Now, there are possible downsides to this: - the "buffer using object_array" _can_ in theory result in at least better I-cache usage (two tight loops rather than one more spread out one). I don't think this is a real issue, but in theory.. - this _does_ change the order of the objects printed. Instead of doing a "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop over the commits (which puts all the root trees _first_ in the object list, this patch just adds them to the list of pending objects, and then we'll traverse them in that order (and thus show each root tree object together with the objects we discover under it) I _think_ the new ordering actually makes more sense, but the object ordering is actually a subtle thing when it comes to packing efficiency, so any change in order is going to have implications for packing. Good or bad, I dunno. - There may be some reason why we did it that odd way with the object array, that I have simply forgotten. Anyway, now that we don't buffer up the objects before showing them that may actually result in lower memory usage during that whole traverse_commit_list() phase. This is seriously not very deeply tested. It makes sense to me, it seems to pass all the tests, it looks ok, but... Does anybody remember why we did that "object_array" thing? It used to be an "object_list" a long long time ago, but got changed into the array due to better memory usage patterns (those linked lists of obejcts are horrible from a memory allocation standpoint). But I wonder why we didn't do this back then. Maybe there's a reason for it. Or maybe there _used_ to be a reason, and no longer is. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 3月, 2009 1 次提交
-
-
由 Brandon Casey 提交于
This option to pack-objects/rev-list was created to improve the -A and -a options of repack. It was found to be lacking in that it did not provide the ability to differentiate between local and non-local kept packs, and found to be unnecessary since objects residing in local kept packs can be filtered out by the --honor-pack-keep option. Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 2月, 2009 4 次提交
-
-
由 Junio C Hamano 提交于
Now is_kept_pack() is just a member lookup into a structure, we can write it as such. Also rewrite the sole caller of has_sha1_kept_pack() to switch on the criteria the callee uses (namely, revs->kept_pack_only) between calling has_sha1_kept_pack() and has_sha1_pack(), so that these two callees do not have to take a pointer to struct rev_info as an argument. This removes the header file dependency issue temporarily introduced by the earlier commit, so we revert changes associated to that as well. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
This removes --unpacked=<packfile> parameter from the revision parser, and rewrites its use in git-repack to pass a single --kept-pack-only option instead. The new --kept-pack-only option means just that. When this option is given, is_kept_pack() that used to say "not on the --unpacked=<packfile> list" now says "the packfile has corresponding .keep file". Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Its "ignore_packed" parameter always comes from struct rev_info. This patch makes the function take a pointer to the surrounding structure, so that the refactoring in the next patch becomes easier to review. There is an unfortunate header file dependency and the easiest workaround is to temporarily move the function declaration from cache.h to revision.h; this will be moved back to cache.h once the function loses this "ignore_packed" parameter altogether in the later part of the series. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Most of the callers of this function except only one pass NULL to its last parameter, ignore_packed. Introduce has_sha1_kept_pack() function that has the function signature and the semantics of this function, and convert the sole caller that does not pass NULL to call this new function. All other callers and has_sha1_pack() lose the ignore_packed parameter. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 2月, 2009 2 次提交
-
-
由 Nanako Shiraishi 提交于
These two are often used together but are too long to type. Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nanako Shiraishi 提交于
Some people prefer to call the pretty-print styles "format", and get annoyed to see "git log --format=short" fail. Introduce it as a synonym to --pretty so that both can be used. Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 2月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
cc0e6c5a (Handle return code of parse_commit in revision machinery, 2007-05-04) attempted to tighten error checking in the revision machinery, but it wasn't enough. When get_revision_1() was asked for the next commit to return, it tries to read and simplify the parents of the commit to be returned, but an error while doing so was silently ignored and reported as a truncated history to the caller instead. This resulted in an early end of "git log" output or a pack that lacks older commits from "git pack-objects", without any error indication in the exit status from these commands, even though the underlying parse_commit() issues an error message to the end user. Note that the codepath in add_parents_list() that paints parents of an UNINTERESTING commit UNINTERESTING silently ignores the error when parse_commit() fails; this is deliberate and in line with aeeae1b7 (revision traversal: allow UNINTERESTING objects to be missing, 2009-01-27). Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 1月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
Most of the existing codepaths were meant to treat missing uninteresting objects to be a silently ignored non-error, but there were a few places in handle_commit() and add_parents_to_list(), which are two key functions in the revision traversal machinery, that cared: - When a tag refers to an object that we do not have, we barfed. We ignore such a tag if it is painted as UNINTERESTING with this change. - When digging deeper into the ancestry chain of a commit that is already painted as UNINTERESTING, in order to paint its parents UNINTERESTING, we barfed if parse_parent() for a parent commit object failed. We can ignore such a parent commit object. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 1月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
When HEAD is detached, --all should list it, too, logically, as a detached HEAD is by definition a temporary, unnamed branch. It is especially necessary to list it when garbage collecting, as the detached HEAD would be trashed. Noticed by Thomas Rast. Note that this affects creating bundles with --all; I contend that it is a good change to add the HEAD, so that cloning from such a bundle will give you a current branch. However, I had to fix t5701 as it assumed that --all does not imply HEAD. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 11月, 2008 1 次提交
-
-
由 Brandon Casey 提交于
A type char** was being used instead of char*. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 11月, 2008 3 次提交
-
-
由 Linus Torvalds 提交于
With this, you can simplify history not by the contents of the tree, but whether a commit has been named (ie it's referred to by some branch or tag) or not. This makes it possible to see the relationship between different named commits, without actually seeing any of the details. When used with pathspec, you would get the usual view that is limited to the commits that change the contents of the tree plus commits that are named. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
This will make it easier to do various clever things that don't depend on the pure tree contents. It also makes the parameter passing much simpler - the callers doesn't really look at trees anywhere else, and it's really the function that should look at the low-level details. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
We already support decorating commits by tags or branches that point to them, but especially when we are looking at multiple branches together, we sometimes want to see _how_ we reached a particular commit. We can abuse the '->util' field in the commit to keep track of that as we walk the commit lists, and get a reasonably useful view into which branch or tag first reaches that commit. Of course, if the commit is reachable through multiple sources (which is common), our particular choice of "first" reachable is entirely random and depends on the particular path we happened to follow. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 9月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
When we tried to find commits done by AUTHOR, the first implementation tried to pattern match a line with "^author .*AUTHOR", which later was enhanced to strip leading caret and look for "^author AUTHOR" when the search pattern was anchored at the left end (i.e. --author="^AUTHOR"). This had a few problems: * When looking for fixed strings (e.g. "git log -F --author=x --grep=y"), the regexp internally used "^author .*x" would never match anything; * To match at the end (e.g. "git log --author='google.com>$'"), the generated regexp has to also match the trailing timestamp part the commit header lines have. Also, in order to determine if the '$' at the end means "match at the end of the line" or just a literal dollar sign (probably backslash-quoted), we would need to parse the regexp ourselves. An earlier alternative tried to make sure that a line matches "^author " (to limit by field name) and the user supplied pattern at the same time. While it solved the -F problem by introducing a special override for matching the "^author ", it did not solve the trailing timestamp nor tail match problem. It also would have matched every commit if --author=author was asked for, not because the author's email part had this string, but because every commit header line that talks about the author begins with that field name, regardleses of who wrote it. Instead of piling more hacks on top of hacks, this rethinks the grep machinery that is used to look for strings in the commit header, and makes sure that (1) field name matches literally at the beginning of the line, followed by a SP, and (2) the user supplied pattern is matched against the remainder of the line, excluding the trailing timestamp data. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 8月, 2008 1 次提交
-
-
由 Thomas Rast 提交于
--reverse did not interact well with --parents, as the included test case shows: in a history like A--B. \ \ `C--M--D the command git rev-list --reverse --parents --full-history HEAD erroneously lists D as having no parents at all. (Without --reverse, it correctly lists M.) This is caused by the machinery driving --reverse: it first grabs all commits through the normal routines, then runs them through the same routines again, effectively simplifying them twice. Fix this by moving the --reverse one level up, into get_revision(). This way we can cleanly grab all commits via the normal calls, then just pop them off the list one by one without interfering with get_revision_internal(). Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 8月, 2008 1 次提交
-
-
由 Jeff King 提交于
This has been broken in v1.6.0 due to the reorganization of the revision option parsing code. The "-i" is completely ignored, but works fine in "git log --grep -i". What happens is that the code for "-i" looks for revs->grep_filter; if it is NULL, we do nothing, since there are no grep filters. But that is obviously not correct, since we want it to influence the later --grep option. Doing it the other way around works, since "-i" just impacts the existing grep_filter option. Instead, we now always initialize the grep_filter member and just fill in options and patterns as we get them. This means that we can no longer check grep_filter for NULL, but instead must check the pattern list to see if we have any actual patterns. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 8月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
When we are not pruning there is no reason to run the merge simplification. Also avoid running topo-order sort twice. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
When we still do not know how parents of a commit simplify to, we should defer processing of the commit, not discard it. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 8月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
The users of revision walking machinery may want to use the util pointer for their own use. Use decoration to hold the data needed during merge simplification instead. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 8月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
This makes the algorithm more honest about what it is doing. We start from an already limited, topo-sorted list, and postprocess it by simplifying the irrelevant merges away. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 8月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
The --full-history traversal keeps all merges in addition to non-merge commits that touch paths in the given pathspec. This is useful to view both sides of a merge in a topology like this: A---M---o / / ---O---B even when A and B makes identical change to the given paths. The revision traversal without --full-history aims to come up with the simplest history to explain the final state of the tree, and one of the side branches can be pruned away. The behaviour to keep all merges however is inconvenient if neither A nor B touches the paths we are interested in. --full-history reduces the topology to: ---O---M---o in such a case, without removing M. This adds a post processing phase on top of --full-history traversal to remove needless merges from the resulting history. The idea is to compute, for each commit in the "full history" result set, the commit that should replace it in the simplified history. The commit to replace it in the final history is determined as follows: * In any case, we first figure out the replacement commits of parents of the commit we are looking at. The commit we are looking at is rewritten as if the replacement commits of its original parents are its parents. While doing so, we reduce the redundant parents from the rewritten parent list by not just removing the identical ones, but also removing a parent that is an ancestor of another parent. * After the above parent simplification, if the commit is a root commit, an UNINTERESTING commit, a merge commit, or modifies the paths we are interested in, then the replacement commit of the commit is itself. In other words, such a commit is not dropped from the final result. The first point above essentially means that the history is rewritten in the bottom up direction. We can rewrite the parent list of a commit only after we know how all of its parents are rewritten. This means that the processing needs to happen on the full history (i.e. after limit_list()). Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 8月, 2008 1 次提交
-
-
由 Pierre Habouzit 提交于
Commands which use parse_options() but also call setup_revisions() must do their parsing in a two step process: 1. first, they parse all options. Anything unknown goes to parse_revision_opt() (which calls handle_revision_opt), which may claim the option or say "I don't recognize this" 2. the non-option remainder goes to setup_revisions() to actually get turned into revisions Some revision options are "non-options" in that they must be parsed in order with their revision counterparts in setup_revisions(). For example, "--all" functions as a pseudo-option expanding to all refs, and "--no-walk" affects refs after it on the command line, but not before. The revision option parser in step 1 recognizes such options and sets them aside for later parsing by setup_revisions(). However, the return value used from handle_revision_opt indicated "I didn't recognize this", which was wrong. It did, and it took appropriate action (even though that action was just deferring it for later parsing). Thus it should return "yes, I recognized this." Previously, these pseudo-options generated an error when used with parse_options parsers (currently just blame and shortlog). With this patch, they should work fine, enabling things like "git shortlog --all". Signed-off-by: NJeff King <peff@peff.net> Acked-By: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 7月, 2008 1 次提交
-
-
由 Dmitry Potapov 提交于
If PATH_MAX on your system is smaller than a path stored, it may cause buffer overflow and stack corruption in diff_addremove() and diff_change() functions when running git-diff Signed-off-by: NDmitry Potapov <dpotapov@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 7月, 2008 1 次提交
-
-
由 Alexander N. Gavrilov 提交于
Parent commits are usually older than their children. Thus, on each iteration of the loop in rewrite_one, add_parents_to_list traverses all commits previously processed by the loop. It performs very poorly in case of very long rewrite chains. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 7月, 2008 1 次提交
-
-
由 Pierre Habouzit 提交于
It seems we're using handle_revision_opt the same way each time, have a wrapper around it that does the 9-liner we copy each time instead. handle_revision_opt can be static in the module for now, it's always possible to make it public again if needed. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 7月, 2008 1 次提交
-
-
由 Pierre Habouzit 提交于
Add two fields to struct rev_info: - .def to store --default argument; and - .show_merge 1-bit field. handle_revision_opt() is able to deal with any revision option, and consumes them, and leaves revision arguments or pseudo arguments (like --all, --not, ...) in place. For now setup_revisions() does a pass of handle_revision_opt() again so that code not using it in a parse-opt parser still work the same. Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 7月, 2008 1 次提交
-
-
由 Adam Brewster 提交于
Reading rev-list parameters from the command line can be reused by commands other than rev-list. Move this function to more "library-ish" place to promote code reuse. Signed-off-by: NAdam Brewster <asb@bu.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 5月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
... nor bogus "format.pretty = '=short'". Both are syntax errors. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
An obvious fix to the argument parser. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-