summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2012-12-11shortlog: fix wrapping lines of wraplenLibravatar Steffen Prohaska1-3/+2
A recent commit [1] fixed a off-by-one wrapping error. As a side-effect, the conditional in add_wrapped_shortlog_msg() to decide whether to append a newline needs to be removed. The function should always append a newline, which was the case before the off-by-one fix, because strbuf_add_wrapped_text() never returns a value of wraplen; when it returns wraplen, the string does not end with a newline, so this caller needs to add one anyway. [1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one wrapping of text Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'jk/maint-quiet-is-synonym-to-s-in-log' into maint-1.7.11Libravatar Junio C Hamano1-1/+1
* jk/maint-quiet-is-synonym-to-s-in-log: log: fix --quiet synonym for -s
2012-09-14Merge branch 'jc/maint-ident-missing-human-name' into maint-1.7.11Libravatar Junio C Hamano1-1/+16
* jc/maint-ident-missing-human-name: split_ident_line(): make best effort when parsing author/committer line
2012-09-12Merge branch 'jc/apply-binary-p0' into maint-1.7.11Libravatar Junio C Hamano1-25/+43
"git apply -p0" did not parse pathnames on "diff --git" line correctly. This caused patches that had pathnames in no other places to be mistakenly rejected (most notably, binary patch that does not rename nor change mode). Textual patches, renames or mode changes have preimage and postimage pathnames in different places in a form that can be parsed unambiguously and did not suffer from this problem. * jc/apply-binary-p0: apply: compute patch->def_name correctly under -p0
2012-09-12Merge branch 'jc/dotdot-is-parent-directory' into maint-1.7.11Libravatar Junio C Hamano1-2/+14
"git log .." errored out saying it is both rev range and a path when there is no disambiguating "--" is on the command line. Update the command line parser to interpret ".." as a path in such a case. * jc/dotdot-is-parent-directory: specifying ranges: we did not mean to make ".." an empty set
2012-09-12Merge branch 'kk/maint-for-each-ref-multi-sort' into maint-1.7.11Libravatar Junio C Hamano1-1/+3
"git for-each-ref" did not honor multiple "--sort=<key>" arguments correctly. * kk/maint-for-each-ref-multi-sort: for-each-ref: Fix sort with multiple keys t6300: test sort with multiple keys
2012-09-11Merge branch 'jc/maint-config-exit-status' into maint-1.7.11Libravatar Junio C Hamano1-2/+6
* jc/maint-config-exit-status: config: "git config baa" should exit with status 1
2012-09-11Merge branch 'tr/void-diff-setup-done' into maint-1.7.11Libravatar Junio C Hamano4-12/+6
* tr/void-diff-setup-done: diff_setup_done(): return void
2012-09-11Merge branch 'pg/maint-apply-remove-unused-variable' into maint-1.7.11Libravatar Junio C Hamano1-1/+0
* pg/maint-apply-remove-unused-variable: apply: delete unused deflate_origlen from patch struct
2012-09-10Merge branch 'bc/receive-pack-stdout-protection' into maint-1.7.11Libravatar Junio C Hamano1-1/+2
When "git push" triggered the automatic gc on the receiving end, a message from "git prune" that said it was removing cruft leaked to the standard output, breaking the communication protocol. * bc/receive-pack-stdout-protection: receive-pack: do not leak output from auto-gc to standard output t/t5400: demonstrate breakage caused by informational message from prune
2012-09-10Merge branch 'jk/maint-null-in-trees' into maint-1.7.11Libravatar Junio C Hamano3-7/+12
"git diff" had a confusion between taking data from a path in the working tree and taking data from an object that happens to have name 0{40} recorded in a tree. * jk/maint-null-in-trees: fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value
2012-08-31split_ident_line(): make best effort when parsing author/committer lineLibravatar Junio C Hamano1-1/+16
Commits made by ancient version of Git allowed committer without human readable name, like this (00213b17c in the kernel history): tree 6947dba41f8b0e7fe7bccd41a4840d6de6a27079 parent 352dd1df32e672be4cff71132eb9c06a257872fe author Petr Baudis <pasky@ucw.cz> 1135223044 +0100 committer <sam@mars.ravnborg.org> 1136151043 +0100 kconfig: Remove support for lxdialog --checklist ... Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> When fed such a commit, --format='%ci' fails to parse it, and gives back an empty string. Update the split_ident_line() to be a bit more lenient when parsing, but make sure the caller that wants to pick up sane value from its return value does its own validation. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-28log: fix --quiet synonym for -sLibravatar Jeff King1-1/+1
Originally the "--quiet" option was parsed by the diff-option parser into the internal QUICK option. This had the effect of silencing diff output from the log (which was not intended, but happened to work and people started to use it). But it also had other odd side effects at the diff level (for example, it would suppress the second commit in "git show A B"). To fix this, commit 1c40c36 converted log to parse-options and handled the "quiet" option separately, not passing it on to the diff code. However, it simply ignored the option, which was a regression for people using it as a synonym for "-s". Commit 01771a8 then fixed that by interpreting the option to add DIFF_FORMAT_NO_OUTPUT to the list of output formats. However, that commit did not fix it in all cases. It sets the flag after setup_revisions is called. Naively, this makes sense because you would expect the setup_revisions parser to overwrite our output format flag if "-p" or another output format flag is seen. However, that is not how the NO_OUTPUT flag works. We actually store it in the bit-field as just another format. At the end of setup_revisions, we call diff_setup_done, which post-processes the bitfield and clears any other formats if we have set NO_OUTPUT. By setting the flag after setup_revisions is done, diff_setup_done does not have a chance to make this tweak, and we end up with other format options still set. As a result, the flag would have no effect in "git log -p --quiet" or "git show --quiet". Fix it by setting the format flag before the call to setup_revisions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-24apply: compute patch->def_name correctly under -p0Libravatar Junio C Hamano1-25/+43
Back when "git apply" was written, we made sure that the user can skip more than the default number of path components (i.e. 1) by giving "-p<n>", but the logic for doing so was built around the notion of "we skip N slashes and stop". This obviously does not work well when running under -p0 where we do not want to skip any, but still want to skip SP/HT that separates the pathnames of preimage and postimage and want to reject absolute pathnames. Stop using "stop_at_slash()", and instead introduce a new helper "skip_tree_prefix()" with similar logic but works correctly even for the -p0 case. This is an ancient bug, but has been masked for a long time because most of the patches are text and have other clues to tell us the name of the preimage and the postimage. Noticed by Colin McCabe. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-24Merge branch 'jk/maint-commit-check-committer-early' into maint-1.7.11Libravatar Junio C Hamano1-1/+1
* jk/maint-commit-check-committer-early: commit: check committer identity more strictly
2012-08-23specifying ranges: we did not mean to make ".." an empty setLibravatar Junio C Hamano1-2/+14
Either end of revision range operator can be omitted to default to HEAD, as in "origin.." (what did I do since I forked) or "..origin" (what did they do since I forked). But the current parser interprets ".." as an empty range "HEAD..HEAD", and worse yet, because ".." does exist on the filesystem, we get this annoying output: $ cd Documentation/howto $ git log .. ;# give me recent commits that touch Documentation/ area. fatal: ambiguous argument '..': both revision and filename Use '--' to separate filenames from revisions Surely we could say "git log ../" or even "git log -- .." to disambiguate, but we shouldn't have to. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21for-each-ref: Fix sort with multiple keysLibravatar Kacper Kornet1-1/+3
The linked list describing sort options was not correctly set up in opt_parse_sort. In the result, contrary to the documentation, only the last of multiple --sort options to git-for-each-ref was taken into account. This commit fixes it. Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-06receive-pack: do not leak output from auto-gc to standard outputLibravatar Junio C Hamano1-1/+2
The standard output channel of receive-pack is a structured protocol channel, and subprocesses must never be allowed to leak anything into it by writing to their standard output. Use RUN_COMMAND_STDOUT_TO_STDERR option to run_command_v_opt() just like we do when running hooks to prevent output from "gc" leaking to the standard output. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-06Merge branch 'jk/maint-checkout-orphan-check-fix' into maintLibravatar Junio C Hamano1-1/+1
* jk/maint-checkout-orphan-check-fix: checkout: don't confuse ref and object flags
2012-08-05apply: delete unused deflate_origlen from patch structLibravatar Paul Gortmaker1-1/+0
It hasn't been used since 2006, as of commit 3cd4f5e8 "git-apply --binary: clean up and prepare for --reverse" Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-03diff_setup_done(): return voidLibravatar Thomas Rast4-12/+6
diff_setup_done() has historically returned an error code, but lost the last nonzero return in 943d5b7 (allow diff.renamelimit to be set regardless of -M/-C, 2006-08-09). The callers were in a pretty confused state: some actually checked for the return code, and some did not. Let it return void, and patch all callers to take this into account. This conveniently also gets rid of a handful of different(!) error messages that could never be triggered anyway. Note that the function can still die(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30Merge branch 'kk/maint-commit-tree' into maintLibravatar Junio C Hamano1-3/+0
"git commit-tree" learned a more natural "-p <parent> <tree>" order of arguments long time ago, but recently forgot it by mistake. * kk/maint-commit-tree: Revert "git-commit-tree(1): update synopsis" commit-tree: resurrect command line parsing updates
2012-07-30config: "git config baa" should exit with status 1Libravatar Junio C Hamano1-2/+6
We instead failed with an undocumented exit status 255. Also define a "catch-all" status and document it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29diff: do not use null sha1 as a sentinel valueLibravatar Jeff King3-7/+12
The diff code represents paths using the diff_filespec struct. This struct has a sha1 to represent the sha1 of the content at that path, as well as a sha1_valid member which indicates whether its sha1 field is actually useful. If sha1_valid is not true, then the filespec represents a working tree file (e.g., for the no-index case, or for when the index is not up-to-date). The diff_filespec is only used internally, though. At the interfaces to the diff subsystem, callers feed the sha1 directly, and we create a diff_filespec from it. It's at that point that we look at the sha1 and decide whether it is valid or not; callers may pass the null sha1 as a sentinel value to indicate that it is not. We should not typically see the null sha1 coming from any other source (e.g., in the index itself, or from a tree). However, a corrupt tree might have a null sha1, which would cause "diff --patch" to accidentally diff the working tree version of a file instead of treating it as a blob. This patch extends the edges of the diff interface to accept a "sha1_valid" flag whenever we accept a sha1, and to use that flag when creating a filespec. In some cases, this means passing the flag through several layers, making the code change larger than would be desirable. One alternative would be to simply die() upon seeing corrupted trees with null sha1s. However, this fix more directly addresses the problem (while bogus sha1s in a tree are probably a bad thing, it is really the sentinel confusion sending us down the wrong code path that is what makes it devastating). And it means that git is more capable of examining and debugging these corrupted trees. For example, you can still "diff --raw" such a tree to find out when the bogus entry was introduced; you just cannot do a "--patch" diff (just as you could not with any other corrupted tree, as we do not have any content to diff). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-25checkout: don't confuse ref and object flagsLibravatar Jeff King1-1/+1
When we are leaving a detached HEAD, we do a revision traversal to check whether we are orphaning any commits, marking the commit we're leaving as the start of the traversal, and all existing refs as uninteresting. Prior to commit 468224e5, we did so by calling for_each_ref, and feeding each resulting refname to setup_revisions. Commit 468224e5 refactored this to simply mark the pending objects, saving an extra lookup. However, it confused the "flags" parameter to the each_ref_fn clalback, which is about the flags we found while looking up the ref with the object flag. Because REF_ISSYMREF ("this ref is a symbolic ref, e.g. refs/remotes/origin/HEAD") happens to be the same bit pattern as SEEN ("we have picked this object up from the pending list and moved it to revs.commits list"), we incorrectly reported that a commit previously at the detached HEAD will become unreachable if the only ref that can reach the commit happens to be pointed at by a symbolic ref. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-23commit: check committer identity more strictlyLibravatar Jeff King1-1/+1
The identity of the committer will ultimately be pulled from the ident code by commit_tree(). However, we make an attempt to check the author and committer identity early, before the user has done any manual work like inputting a commit message. That lets us abort without them having to worry about salvaging the work from .git/COMMIT_EDITMSG. The early check for committer ident does not use the IDENT_STRICT flag, meaning that it would not find an empty name field. The motivation was presumably because we did not want to be too restrictive, as later calls might be more lax (for example, when we create the reflog entry, we do not care too much about a real name). However, because commit_tree will always get a strict identity to put in the commit object itself, there is no point in being lax only to die later (and in fact it is harmful, because the user will have wasted time typing their commit message). Incidentally, this bug was masked prior to 060d4bb, as the initial loose call would taint the later strict call. So the commit would succeed (albeit with a bogus committer line in the commit object), and nobody noticed that our early check did not match the later one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Merge branch 'ar/clone-honor-umask-at-top' into maintLibravatar Junio C Hamano2-2/+2
A handful of files and directories we create had tighter than necessary permission bits when the user wanted to have group writability (e.g. by setting "umask 002"). * ar/clone-honor-umask-at-top: add: create ADD_EDIT.patch with mode 0666 rerere: make rr-cache fanout directory honor umask Restore umasks influence on the permissions of work tree created by clone
2012-07-22Merge branch 'cw/amend-commit-without-message' into maintLibravatar Junio C Hamano1-1/+1
"commit --amend" used to refuse amending a commit with an empty log message, with or without "--allow-empty-message". * cw/amend-commit-without-message: Allow edit of empty message with commit --amend
2012-07-22Merge branch 'jk/maint-commit-amend-only-no-paths' into maintLibravatar Junio C Hamano1-1/+4
"git commit --amend --only --" was meant to allow "Clever" people to rewrite the commit message without making any change even when they have already changes for the next commit added to their index, but it never worked as advertised since it was introduced in 1.3.0 era. * jk/maint-commit-amend-only-no-paths: commit: fix "--amend --only" with no pathspec
2012-07-22Merge branch 'tr/maint-show-walk' into maintLibravatar Junio C Hamano1-0/+3
"git show"'s auto-walking behaviour was an unreliable and unpredictable hack; it now behaves just like "git log" does when it walks. * tr/maint-show-walk: show: fix "range implies walking" Demonstrate git-show is broken with ranges
2012-07-22Merge branch 'js/fast-export-paths-with-spaces' into maintLibravatar Junio C Hamano1-0/+2
"git fast-export" produced an input stream for fast-import without properly quoting pathnames when they contain SPs in them. * js/fast-export-paths-with-spaces: fast-export: quote paths with spaces
2012-07-22Merge branch 'cw/no-detaching-an-unborn' into maintLibravatar Junio C Hamano1-0/+2
"git checkout --detach", when you are still on an unborn branch, should be forbidden, but it wasn't. * cw/no-detaching-an-unborn: git-checkout: disallow --detach on unborn branch
2012-07-17Merge branch 'kk/maint-1.7.9-commit-tree' into kk/maint-commit-treeLibravatar Junio C Hamano1-3/+0
* kk/maint-1.7.9-commit-tree: commit-tree: resurrect command line parsing updates
2012-07-17commit-tree: resurrect command line parsing updatesLibravatar Junio C Hamano1-3/+0
79a9312 (commit-tree: update the command line parsing, 2011-11-09) updated the command line parser to understand the usual "flags first and then non-flag arguments" order, in addition to the original and a bit unusual "tree comes first and then zero or more -p <parent>". Unfortunately, ba3c69a (commit: teach --gpg-sign option, 2011-10-05) broke it by mistake. Resurrect it, and protect the feature with a test from future breakages. Noticed by Keshav Kini Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-11Merge branch 'jc/maint-blame-unique-abbrev' into maintLibravatar Junio C Hamano1-4/+21
"git blame" did not try to make sure that the abbreviated commit object names in its output are unique. * jc/maint-blame-unique-abbrev: blame: compute abbreviation width that ensures uniqueness
2012-07-11Merge branch 'rj/platform-pread-may-be-thread-unsafe' into maintLibravatar Junio C Hamano1-2/+2
On Cygwin, the platform pread(2) is not thread safe, just like our own compat/ emulation, and cannot be used in the index-pack program. Makefile variable NO_THREAD_SAFE_PREAD can be defined to avoid use of this function in a threaded program. * rj/platform-pread-may-be-thread-unsafe: index-pack: Disable threading on cygwin
2012-07-11Merge branch 'nd/clone-single-fix' into maintLibravatar Junio C Hamano1-2/+5
"git clone --single-branch" to clone a single branch did not limit the cloning to the specified branch. * nd/clone-single-fix: clone: fix ref selection in --single-branch --branch=xxx
2012-07-11Merge branch 'hv/submodule-update-nuke-submodules' into maintLibravatar Junio C Hamano1-6/+0
"git add" allows adding a regular file to the path where a submodule used to exist, but "git update-index" did not allow an equivalent operation to Porcelain writers. * hv/submodule-update-nuke-submodules: update-index: allow overwriting existing submodule index entries
2012-07-11Merge branch 'jk/diff-no-index-pager' into maintLibravatar Junio C Hamano1-7/+17
"git diff --no-index" did not work with pagers correctly. * jk/diff-no-index-pager: do not run pager with diff --no-index --quiet fix pager.diff with diff --no-index
2012-07-11Merge branch 'mm/verify-filename-fix' into maintLibravatar Junio C Hamano3-4/+4
"git diff COPYING HEAD:COPYING" gave a nonsense error message that claimed that the treeish HEAD did not have COPYING in it. * mm/verify-filename-fix: verify_filename(): ask the caller to chose the kind of diagnosis sha1_name: do not trigger detailed diagnosis for file arguments
2012-07-11Merge branch 'jc/ls-files-i-dir' into maintLibravatar Junio C Hamano2-7/+22
"git ls-files --exclude=t -i" did not consider anything under t/ as excluded, as it did not pay attention to exclusion of leading paths while walking the index. Other two users of excluded() are also updated. * jc/ls-files-i-dir: dir.c: make excluded() file scope static unpack-trees.c: use path_excluded() in check_ok_to_remove() builtin/add.c: use path_excluded() path_excluded(): update API to less cache-entry centric ls-files -i: micro-optimize path_excluded() ls-files -i: pay attention to exclusion of leading paths
2012-07-09add: create ADD_EDIT.patch with mode 0666Libravatar Jeff King1-1/+1
We should be letting the user's umask take care of restricting permissions. Even though this is a temporary file and probably nobody would notice, this brings us in line with other temporary file creations in git (e.g., choosing "e"dit from git-add--interactive). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Restore umasks influence on the permissions of work tree created by cloneLibravatar Alex Riesen1-1/+1
The original version of the git-clone just used mkdir(1) to create the working directories. The version rewritten in C creates all directories inside the working tree by using the mode argument of 0777 when calling mkdir(2) to let the umask take effect. But the top-level directory of the working tree is created by passing the mode argument of 0755 to mkdir(2), which results in an overly tight restriction if the user wants to make directories group writable with a looser umask like 002. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09Allow edit of empty message with commit --amendLibravatar Chris Webb1-1/+1
"git commit --amend" used on a commit with an empty message fails unless -m is given, whether or not --allow-empty-message is specified. Allow it to proceed to the editor with an empty commit message. Unless --allow-empty-message is in force, it will still abort later if an empty message is saved from the editor (this check was already necessary to prevent a non-empty commit message being edited to an empty one). Add a test for --amend --edit of an empty commit message which fails without this fix, as it's a rare case that won't get frequently tested otherwise. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-02blame: compute abbreviation width that ensures uniquenessLibravatar Junio C Hamano1-4/+21
Julia Lawall noticed that in linux-next repository the commit object 60d5c9f5 (shown with the default abbreviation width baked into "git blame") in output from $ git blame -L 3675,3675 60d5c9f5b -- \ drivers/staging/brcm80211/brcmfmac/wl_iw.c is no longer unique in the repository, which results in "short SHA1 60d5c9f5 is ambiguous". Compute the minimum abbreviation width that ensures uniqueness when the user did not specify the --abbrev option to avoid this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-27fast-export: quote paths with spacesLibravatar Jay Soffian1-0/+2
A path containing a space must be quoted when used as an argument to either the copy or rename commands (because unlike other commands, the path is not the final thing on the line for those commands). Commit 6280dfdc3b (fast-export: quote paths in output, 2011-08-05) previously attempted to fix fast-export's quoting by passing all paths through quote_c_style(). However, that function does not consider the space to be a character which requires quoting, so let's special-case the space inside print_path(). This will cause space-containing paths to also be quoted in other commands where such quoting is not strictly necessary, but it does not hurt to do so. The test from 6280dfdc3b did not detect this because, while it does introduce renames in the export stream, it does not actually turn on rename detection, so they were presented as pairs of deletions/adds. Using "-M" reveals the bug. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-26index-pack: Disable threading on cygwinLibravatar Junio C Hamano1-2/+2
The Cygwin implementation of pread() is not thread-safe since, just like the emulation provided by compat/pread.c, it uses a sequence of seek-read-seek calls. In order to avoid failues due to thread-safety issues, commit b038a61 disables threading when NO_PREAD is defined. (ie when using the emulation code in compat/pread.c). We introduce a new build variable, NO_THREAD_SAFE_PREAD, which allows use to disable the threaded index-pack code on cygwin, in addition to the above NO_PREAD case. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-26git-checkout: disallow --detach on unborn branchLibravatar Chris Webb1-0/+2
abe199808c (git checkout -b: allow switching out of an unborn branch) introduced a bug demonstrated by git checkout --orphan foo git checkout --detach git symbolic-ref HEAD which gives 'refs/heads/(null)'. This happens because we strbuf_addf(&branch_ref, "refs/heads/%s", opts->new_branch) when opts->new_branch can be NULL for --detach. Catch and forbid this case, adding a test to t2017 to catch it in future. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-22clone: fix ref selection in --single-branch --branch=xxxLibravatar Nguyễn Thái Ngọc Duy1-2/+5
- do not fetch HEAD - do not also fetch refs following "xxx" Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19show: fix "range implies walking"Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>