summaryrefslogtreecommitdiff
path: root/revision.c
AgeCommit message (Collapse)AuthorFilesLines
2010-03-13don't use default revision if a rev was specifiedLibravatar Dave Olszewski1-2/+4
If a revision is specified, it happens not to have any commits, don't use the default revision. By doing so, surprising and undesired behavior can happen, such as showing the reflog for HEAD when a branch was specified. [jc: squashed a test from René] Signed-off-by: Dave Olszewski <cxreg@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-08Merge branch 'jc/grep-author-all-match-implicit' into maintLibravatar Junio C Hamano1-1/+2
* jc/grep-author-all-match-implicit: "log --author=me --grep=it" should find intersection, not union
2010-03-04Merge branch 'tr/maint-cherry-pick-list' into maintLibravatar Junio C Hamano1-0/+3
* tr/maint-cherry-pick-list: cherry_pick_list: quit early if one side is empty
2010-02-20cherry_pick_list: quit early if one side is emptyLibravatar Thomas Rast1-0/+3
The --cherry-pick logic starts by counting the commits on each side, so that it can filter away commits on the bigger one. However, so far it missed an opportunity for optimization: it doesn't need to do any work if either side is empty. This in particular helps the common use-case 'git rebase -i HEAD~$n': it internally uses --cherry-pick, but since HEAD~$n is a direct ancestor the left side is always empty. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26Fix log -g this@{upstream}Libravatar Junio C Hamano1-4/+14
It showed the correct objects but walked a wrong reflog. Again, tests are from Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-25"log --author=me --grep=it" should find intersection, not unionLibravatar Junio C Hamano1-1/+2
Historically, any grep filter in "git log" family of commands were taken as restricting to commits with any of the words in the commit log message. However, the user almost always want to find commits "done by this person on that topic". With "--all-match" option, a series of grep patterns can be turned into a requirement that all of them must produce a match, but that makes it impossible to ask for "done by me, on either this or that" with: log --author=me --committer=him --grep=this --grep=that because it will require both "this" and "that" to appear. Change the "header" parser of grep library to treat the headers specially, and parse it as: (all-match-OR (HEADER-AUTHOR me) (HEADER-COMMITTER him) (OR (PATTERN this) (PATTERN that) ) ) Even though the "log" command line parser doesn't give direct access to the extended grep syntax to group terms with parentheses, this change will cover the majority of the case the users would want. This incidentally revealed that one test in t7002 was bogus. It ran: log --author=Thor --grep=Thu --format='%s' and expected (wrongly) "Thu" to match "Thursday" in the author/committer date, but that would never match, as the timestamp in raw commit buffer does not have the name of the day-of-the-week. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-22Merge branch 'il/rev-glob'Libravatar Junio C Hamano1-2/+32
* il/rev-glob: Documentation: improve description of --glob=pattern and friends rev-parse --branches/--tags/--remotes=pattern rev-parse --glob
2010-01-22Merge branch 'jl/submodule-diff'Libravatar Junio C Hamano1-2/+3
* jl/submodule-diff: Performance optimization for detection of modified submodules git status: Show uncommitted submodule changes too when enabled Teach diff that modified submodule directory is dirty Show submodules as modified when they contain a dirty work tree
2010-01-22Merge branch 'jc/maint-limit-note-output'Libravatar Junio C Hamano1-0/+9
* jc/maint-limit-note-output: Fix "log --oneline" not to show notes Fix "log" family not to be too agressive about showing notes
2010-01-21Fix "log --oneline" not to show notesLibravatar Junio C Hamano1-0/+1
This option should be treated pretty much the same as --format="%h %s". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Fix "log" family not to be too agressive about showing notesLibravatar Junio C Hamano1-0/+8
Giving "Notes" information in the default output format of "log" and "show" is a sensible progress (the user has asked for it by having the notes), but for some commands (e.g. "format-patch") spewing notes into the formatted commit log message without being asked is too aggressive. Enable notes output only for "log", "show", "whatchanged" by default and only when the user didn't ask any specific --pretty/--format from the command line; users can explicitly override this default with --show-notes and --no-notes option. Parts of tests are taken from Jeff King's fix. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20rev-parse --branches/--tags/--remotes=patternLibravatar Ilari Liusvaara1-0/+18
Since local branch, tags and remote tracking branch namespaces are most often used, add shortcut notations for globbing those in manner similar to --glob option. With this, one can express the "what I have but origin doesn't?" as: 'git log --branches --not --remotes=origin' Original-idea-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20rev-parse --globLibravatar Ilari Liusvaara1-2/+14
Add --glob=<glob-pattern> option to rev-parse and everything that accepts its options. This option matches all refs that match given shell glob pattern (complete with some DWIM logic). Example: 'git log --branches --not --glob=remotes/origin' To show what you have that origin doesn't. Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-18Performance optimization for detection of modified submodulesLibravatar Jens Lehmann1-2/+3
In the worst case is_submodule_modified() got called three times for each submodule. The information we got from scanning the whole submodule tree the first time can be reused instead. New parameters have been added to diff_change() and diff_addremove(), the information is stored in a new member of struct diff_filespec. Its value is then reused instead of calling is_submodule_modified() again. When no explicit "-dirty" is needed in the output the call to is_submodule_modified() is not necessary when the submodules HEAD already disagrees with the ref of the superproject, as this alone marks it as modified. To achieve that, get_stat_data() got an extra argument. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-26Merge branch 'jc/1.7.0-diff-whitespace-only-status'Libravatar Junio C Hamano1-1/+1
* jc/1.7.0-diff-whitespace-only-status: diff.c: fix typoes in comments Make test case number unique diff: Rename QUIET internal option to QUICK diff: change semantics of "ignore whitespace" options Conflicts: diff.h
2009-11-23Merge branch 'jc/log-stdin'Libravatar Junio C Hamano1-13/+93
* jc/log-stdin: Add trivial tests for --stdin option to log family Make --stdin option to "log" family read also pathspecs setup_revisions(): do not call get_pathspec() too early Teach --stdin option to "log" family read_revision_from_stdin(): use strbuf Conflicts: revision.c
2009-11-20Make --stdin option to "log" family read also pathspecsLibravatar Junio C Hamano1-4/+68
Similar to the command line arguments, after giving zero or more revs, you can feed a line "--" and then feed pathspecs one at a time. With this ( echo ^maint echo -- echo Documentation ) | git log --stat --oneline --stdin master -- t lists commits that touch Documentation/ or t/ between maint and master. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20setup_revisions(): do not call get_pathspec() too earlyLibravatar Junio C Hamano1-3/+6
This is necessary because we will later allow pathspecs to be fed from the standard input, and pathspecs taken from the command line (and converted via get_pathspec() already) in revs->prune_data too early gets in the way when we want to append from the standard input. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20Teach --stdin option to "log" familyLibravatar Junio C Hamano1-2/+13
Move the logic to read revs from standard input that rev-list knows about from it to revision machinery, so that all the users of setup_revisions() can feed the list of revs from the standard input when "--stdin" is used on the command line. Allow some users of the revision machinery that want different semantics from the "--stdin" option to disable it by setting an option in the rev_info structure. This also cleans up the kludge made to bundle.c via cut and paste. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20read_revision_from_stdin(): use strbufLibravatar Junio C Hamano1-8/+10
It is so 2005 (and Linus ;-) to have a fixed 1000-byte buffer that reads from the user. Let's use strbuf to unlimit the input length. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-28Add '--bisect' revision machinery argumentLibravatar Linus Torvalds1-1/+18
I personally use "git bisect visualize" all the time when I bisect, but it turns out that that is not a very flexible model. Sometimes I want to do bisection based on all commits (no pathname limiting), but then visualize the current bisection tree with just a few pathnames because I _suspect_ those pathnames are involved in the problem but am not totally sure about them. And at other times, I want to use other revision parsing logic, none of which is available with "git bisect visualize". So this adds "--bisect" as a revision parsing argument, and as a result it just works with all the normal logging tools. So now I can just do gitk --bisect --simplify-by-decoration filename-here etc. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-29improve reflog date/number heuristicLibravatar Jeff King1-0/+2
When we show a reflog, we have two ways of naming the entry: by sequence number (e.g., HEAD@{0}) or by date (e.g., HEAD@{10 minutes ago}). There is no explicit option to set one or the other, but we guess based on whether or not the user has provided us with a date format, showing them the date version if they have done so, and the sequence number otherwise. This usually made sense if the use did something like "git log -g --date=relative". However, it didn't make much sense if the user set the date format using the log.date config variable; in that case, all of their reflogs would end up as dates. This patch records the source of the date format and only triggers the date-based view if --date= was given on the command line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-08-27Merge branch 'as/maint-graph-interesting-fix'Libravatar Junio C Hamano1-3/+14
* as/maint-graph-interesting-fix: Add tests for rev-list --graph with options that simplify history graph API: fix bug in graph_is_interesting()
2009-08-21graph API: fix bug in graph_is_interesting()Libravatar Adam Simpkins1-3/+14
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 f29ac4f and 66996ec, among other places. Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-18git-log: allow --decorate[=short|full]Libravatar Lars Hjemli1-1/+1
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: Lars Hjemli <hjemli@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29diff: Rename QUIET internal option to QUICKLibravatar Junio C Hamano1-1/+1
The option "QUIET" primarily meant "find if we have _any_ difference as quick as possible and report", which means we often do not even have to look at blobs if we know the trees are different by looking at the higher level (e.g. "diff-tree A B"). As a side effect, because there is no point showing one change that we happened to have found first, it also enables NO_OUTPUT and EXIT_WITH_STATUS options, making the end result look quiet. Rename the internal option to QUICK to reflect this better; it also makes grepping the source tree much easier, as there are other kinds of QUIET option everywhere. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-14Make 'git show' more usefulLibravatar Linus Torvalds1-1/+1
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: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-29git log: add '--merges' flag to match '--no-merges'Libravatar Linus Torvalds1-0/+4
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: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03Clean up and simplify rev_compare_tree()Libravatar Linus Torvalds1-21/+12
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: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22Fix typos / spelling in commentsLibravatar Mike Ralphson1-1/+1
Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-18Merge branch 'lt/pack-object-memuse'Libravatar Junio C Hamano1-2/+2
* lt/pack-object-memuse: show_object(): push path_name() call further down process_{tree,blob}: show objects without buffering Conflicts: builtin-pack-objects.c builtin-rev-list.c list-objects.c list-objects.h upload-pack.c
2009-04-12show_object(): push path_name() call further downLibravatar Linus Torvalds1-2/+2
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: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12process_{tree,blob}: show objects without bufferingLibravatar Linus Torvalds1-1/+1
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: Junio C Hamano <gitster@pobox.com>
2009-04-01Merge branch 'jc/maint-1.6.0-keep-pack'Libravatar Junio C Hamano1-8/+1
* jc/maint-1.6.0-keep-pack: pack-objects: don't loosen objects available in alternate or kept packs t7700: demonstrate repack flaw which may loosen objects unnecessarily Remove --kept-pack-only option and associated infrastructure pack-objects: only repack or loosen objects residing in "local" packs git-repack.sh: don't use --kept-pack-only option to pack-objects t7700-repack: add two new tests demonstrating repacking flaws Conflicts: t/t7700-repack.sh
2009-03-20Remove --kept-pack-only option and associated infrastructureLibravatar Brandon Casey1-8/+1
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: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-11Merge branch 'jc/maint-1.6.0-keep-pack'Libravatar Junio C Hamano1-16/+9
* jc/maint-1.6.0-keep-pack: is_kept_pack(): final clean-up Simplify is_kept_pack() Consolidate ignore_packed logic more has_sha1_kept_pack(): take "struct rev_info" has_sha1_pack(): refactor "pretend these packs do not exist" interface git-repack: resist stray environment variable
2009-02-28is_kept_pack(): final clean-upLibravatar Junio C Hamano1-1/+3
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: Junio C Hamano <gitster@pobox.com>
2009-02-28Simplify is_kept_pack()Libravatar Junio C Hamano1-15/+5
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: Junio C Hamano <gitster@pobox.com>
2009-02-28has_sha1_kept_pack(): take "struct rev_info"Libravatar Junio C Hamano1-1/+1
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: Junio C Hamano <gitster@pobox.com>
2009-02-28has_sha1_pack(): refactor "pretend these packs do not exist" interfaceLibravatar Junio C Hamano1-1/+2
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: Junio C Hamano <gitster@pobox.com>
2009-02-24Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"Libravatar Nanako Shiraishi1-0/+4
These two are often used together but are too long to type. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-24Add --format that is a synonym to --prettyLibravatar Nanako Shiraishi1-1/+1
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: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-11Merge branch 'maint'Libravatar Junio C Hamano1-2/+4
* maint: revision traversal and pack: notice and die on missing commit
2009-02-11Merge branch 'maint-1.5.6' into maintLibravatar Junio C Hamano1-2/+4
* maint-1.5.6: revision traversal and pack: notice and die on missing commit
2009-02-11Merge branch 'maint-1.5.5' into maint-1.5.6Libravatar Junio C Hamano1-2/+4
* maint-1.5.5: revision traversal and pack: notice and die on missing commit Conflicts: revision.c
2009-02-11Merge branch 'maint-1.5.4' into maint-1.5.5Libravatar Junio C Hamano1-2/+4
* maint-1.5.4: revision traversal and pack: notice and die on missing commit
2009-02-11revision traversal and pack: notice and die on missing commitLibravatar Junio C Hamano1-2/+4
cc0e6c5 (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 aeeae1b (revision traversal: allow UNINTERESTING objects to be missing, 2009-01-27). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-05Merge branch 'js/maint-all-implies-HEAD' into maintLibravatar Junio C Hamano1-0/+1
* js/maint-all-implies-HEAD: bundle: allow the same ref to be given more than once revision walker: include a detached HEAD in --all
2009-01-31Merge branch 'jc/maint-allow-uninteresting-missing'Libravatar Junio C Hamano1-3/+7
* jc/maint-allow-uninteresting-missing: revision traversal: allow UNINTERESTING objects to be missing
2009-01-28revision traversal: allow UNINTERESTING objects to be missingLibravatar Junio C Hamano1-3/+7
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: Junio C Hamano <gitster@pobox.com>