summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-02-17Merge branch 'jc/hidden-refs'Libravatar Junio C Hamano1-0/+24
Allow the server side to redact the refs/ namespace it shows to the client. Will merge to 'master'. * jc/hidden-refs: upload/receive-pack: allow hiding ref hierarchies upload-pack: simplify request validation upload-pack: share more code
2013-02-14Merge branch 'jc/extended-fake-ancestor-for-gitlink'Libravatar Junio C Hamano1-2/+38
Instead of requiring the full 40-hex object names on the index line, we can read submodule commit object names from the textual diff when synthesizing a fake ancestore tree for "git am -3". * jc/extended-fake-ancestor-for-gitlink: apply: verify submodule commit object name better
2013-02-12Merge branch 'maint'Libravatar Junio C Hamano2-3/+3
* maint: Replace filepattern with pathspec for consistency
2013-02-12Replace filepattern with pathspec for consistencyLibravatar Matthieu Moy2-3/+3
pathspec is the most widely used term, and is the one defined in gitglossary.txt. <filepattern> was used only in the synopsys for git-add and git-commit, and in git-add.txt. Get rid of it. This patch is obtained with by running: perl -pi -e 's/filepattern/pathspec/' `git grep -l filepattern` Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-08Merge branch 'jk/apply-similaritly-parsing'Libravatar Junio C Hamano1-4/+6
Make sure the similarity value shown in the "apply --summary" output is sensible, even when the input had a bogus value. * jk/apply-similaritly-parsing: builtin/apply: tighten (dis)similarity index parsing
2013-02-07Merge branch 'jc/fake-ancestor-with-non-blobs' into maintLibravatar Junio C Hamano1-14/+16
Rebasing the history of superproject with change in the submodule has been broken since v1.7.12. * jc/fake-ancestor-with-non-blobs: apply: diagnose incomplete submodule object name better apply: simplify build_fake_ancestor() git-am: record full index line in the patch used while rebasing
2013-02-07Merge branch 'nd/branch-error-cases'Libravatar Junio C Hamano1-9/+15
Fix various error messages and conditions in "git branch", e.g. we advertised "branch -d/-D" to remove one or more branches but actually implemented removal of zero or more branches---request to remove no branches was not rejected. * nd/branch-error-cases: branch: let branch filters imply --list docs: clarify git-branch --list behavior branch: mark more strings for translation branch: give a more helpful message on redundant arguments branch: reject -D/-d without branch name
2013-02-07upload/receive-pack: allow hiding ref hierarchiesLibravatar Junio C Hamano1-0/+24
A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-05Merge branch 'jc/fake-ancestor-with-non-blobs'Libravatar Junio C Hamano1-14/+16
Rebasing the history of superproject with change in the submodule was broken since v1.7.12. * jc/fake-ancestor-with-non-blobs: apply: diagnose incomplete submodule object name better apply: simplify build_fake_ancestor() git-am: record full index line in the patch used while rebasing
2013-02-05apply: verify submodule commit object name betterLibravatar Junio C Hamano1-2/+38
A textual patch also records the submodule commit object name in full. Make the parsing more robust by reading from there and verifying the (possibly abbreviated) name on the index line matches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-04Merge branch 'jk/read-commit-buffer-data-after-free'Libravatar Junio C Hamano2-30/+6
Clarify the ownership rule for commit->buffer field, which some callers incorrectly accessed without making sure it is populated. * jk/read-commit-buffer-data-after-free: logmsg_reencode: lazily load missing commit buffers logmsg_reencode: never return NULL commit: drop useless xstrdup of commit message
2013-02-04Merge branch 'mm/add-u-A-sans-pathspec'Libravatar Junio C Hamano1-1/+43
Forbid "git add -u" and "git add -A" without pathspec run from a subdirectory, to train people to type "." (or ":/") to make the choice of default does not matter. * mm/add-u-A-sans-pathspec: add: warn when -u or -A is used without pathspec
2013-02-04Merge branch 'jc/push-reject-reasons'Libravatar Junio C Hamano2-2/+41
Improve error and advice messages given locally when "git push" refuses when it cannot compute fast-forwardness by separating these cases from the normal "not a fast-forward; merge first and push again" case. * jc/push-reject-reasons: push: finishing touches to explain REJECT_ALREADY_EXISTS better push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further simplify the logic to assign rejection reason push: further clean up fields of "struct ref"
2013-02-04Merge branch 'jk/config-parsing-cleanup'Libravatar Junio C Hamano2-13/+14
Configuration parsing for tar.* configuration variables were broken. Introduce a new config-keyname parser API to make the callers much less error prone. * jk/config-parsing-cleanup: reflog: use parse_config_key in config callback help: use parse_config_key for man config submodule: simplify memory handling in config parsing submodule: use parse_config_key when parsing config userdiff: drop parse_driver function convert some config callbacks to parse_config_key archive-tar: use parse_config_key when parsing config config: add helper function for parsing key names
2013-02-04Merge branch 'jc/custom-comment-char'Libravatar Junio C Hamano7-60/+86
Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"
2013-02-04Merge branch 'nd/edit-branch-desc-while-detached' into maintLibravatar Junio C Hamano1-4/+4
Attempt to "branch --edit-description" an existing branch, while being on a detached HEAD, errored out. * nd/edit-branch-desc-while-detached: branch: no detached HEAD check when editing another branch's description
2013-02-04Merge branch 'jc/help' into maintLibravatar Junio C Hamano1-18/+0
* jc/help: help: include <common-cmds.h> only in one file
2013-02-04Merge branch 'jc/merge-blobs' into maintLibravatar Junio C Hamano2-37/+59
* jc/merge-blobs: Makefile: Replace merge-file.h with merge-blobs.h in LIB_H merge-tree: fix d/f conflicts merge-tree: add comments to clarify what these functions are doing merge-tree: lose unused "resolve_directories" merge-tree: lose unused "flags" from merge_list Which merge_file() function do you mean?
2013-02-03builtin/apply: tighten (dis)similarity index parsingLibravatar John Keeping1-4/+6
This was prompted by an incorrect warning issued by clang [1], and a suggestion by Linus to restrict the range to check for values greater than INT_MAX since these will give bogus output after casting to int. In fact the (dis)similarity index is a percentage, so reject values greater than 100. [1] http://article.gmane.org/gmane.comp.version-control.git/213857 Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Merge branch 'nd/edit-branch-desc-while-detached'Libravatar Junio C Hamano1-4/+4
Attempt to "branch --edit-description" an existing branch, while being on a detached HEAD, errored out. * nd/edit-branch-desc-while-detached: branch: no detached HEAD check when editing another branch's description
2013-02-01Merge branch 'jk/gc-auto-after-fetch'Libravatar Junio C Hamano1-0/+5
Help "fetch only" repositories that do not trigger "gc --auto" often enough. * jk/gc-auto-after-fetch: fetch-pack: avoid repeatedly re-scanning pack directory fetch: run gc --auto after fetching
2013-02-01Merge branch 'jc/no-git-config-in-clone'Libravatar Junio C Hamano1-9/+0
We stopped paying attention to $GIT_CONFIG environment that points at a single configuration file from any command other than "git config" quite a while ago, but "git clone" internally set, exported, and then unexported the variable during its operation unnecessarily. * jc/no-git-config-in-clone: clone: do not export and unexport GIT_CONFIG
2013-02-01Merge branch 'nd/fetch-depth-is-broken'Libravatar Junio C Hamano1-1/+16
"git fetch --depth" was broken in at least three ways. The resulting history was deeper than specified by one commit, it was unclear how to wipe the shallowness of the repository with the command, and documentation was misleading. * nd/fetch-depth-is-broken: fetch: elaborate --depth action upload-pack: fix off-by-one depth calculation in shallow clone fetch: add --unshallow for turning shallow repo into complete one
2013-01-31apply: diagnose incomplete submodule object name betterLibravatar Junio C Hamano1-1/+5
"git am -3" uses this function to build a tree that records how the preimage the patch was created from would have looked like. An abbreviated object name on the index line is ordinarily sufficient for us to figure out the object name the preimage tree would have contained, but a change to a submodule by definition shows an object name of a submodule commit which our repository should not have, and get_sha1_blob() is not an appropriate way to read it (or get_sha1() for that matter). Use get_sha1_hex() and complain if we do not find a full object name there. We could read from the payload part of the patch to learn the full object name of the commit, but the primary user "git rebase" has been fixed to give us a full object name, so this should suffice for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31apply: simplify build_fake_ancestor()Libravatar Junio C Hamano1-14/+12
The local variable sha1_ptr in the build_fake_ancestor() function used to either point at the null_sha1[] (if the ancestor did not have the path) or at sha1[] (if we read the object name into the local array), but 7a98869 (apply: get rid of --index-info in favor of --build-fake-ancestor, 2007-09-17) made the "missing in the ancestor" case unnecessary, hence sha1_ptr, when used, always points at the local array. Get rid of the unneeded variable, and restructure the if/else cascade a bit to make it easier to read. There should be no behaviour change. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31branch: let branch filters imply --listLibravatar Jeff King1-0/+3
Currently, a branch filter like `--contains`, `--merged`, or `--no-merged` is ignored when we are not in listing mode. For example: git branch --contains=foo bar will create the branch "bar" from the current HEAD, ignoring the `--contains` argument entirely. This is not very helpful. There are two reasonable behaviors for git here: 1. Flag an error; the arguments do not make sense. 2. Implicitly go into `--list` mode This patch chooses the latter, as it is more convenient, and there should not be any ambiguity with attempting to create a branch; using `--contains` and not wanting to list is nonsensical. That leaves the case where an explicit modification option like `-d` is given. We already catch the case where `--list` is given alongside `-d` and flag an error. With this patch, we will also catch the use of `--contains` and other filter options alongside `-d`. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30branch: mark more strings for translationLibravatar Nguyễn Thái Ngọc Duy1-5/+6
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30Merge branch 'nd/edit-branch-desc-while-detached' into HEADLibravatar Junio C Hamano1-4/+4
* nd/edit-branch-desc-while-detached: branch: no detached HEAD check when editing another branch's description
2013-01-30branch: give a more helpful message on redundant argumentsLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30branch: reject -D/-d without branch nameLibravatar Nguyễn Thái Ngọc Duy1-2/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30branch: no detached HEAD check when editing another branch's descriptionLibravatar Nguyễn Thái Ngọc Duy1-4/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30Merge branch 'nd/magic-pathspec-from-root'Libravatar Junio C Hamano1-0/+2
When giving arguments without "--" disambiguation, object names that come earlier on the command line must not be interpretable as pathspecs and pathspecs that come later on the command line must not be interpretable as object names. Tweak the disambiguation rule so that ":/" (no other string before or after) is always interpreted as a pathspec, to avoid having to say "git cmd -- :/". * nd/magic-pathspec-from-root: grep: avoid accepting ambiguous revision Update :/abc ambiguity check
2013-01-28Merge branch 'jc/help'Libravatar Junio C Hamano1-18/+0
A header file that has the definition of a static array was included in two places, wasting the space. * jc/help: help: include <common-cmds.h> only in one file
2013-01-28add: warn when -u or -A is used without pathspecLibravatar Matthieu Moy1-1/+43
Most Git commands that can be used with or without pathspec operate tree-wide by default, the pathspec being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. When run in a subdirectory without pathspec, they operate only on paths in the current directory. The inconsistency of 'git add -u' and 'git add -A' is particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. It also means that "git add -u && git commit" will record a state that is different from what is recorded with "git commit -a". Flipping the default now is unacceptable, so let's start training users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to prepare for the next steps: * forbid 'git add -u|-A' without pathspec (like 'git add' without option) * much later, maybe, re-allow 'git add -u|-A' without pathspec, that will add all tracked and modified files, or all files, tree-wide. A nice side effect of this patch is that it makes the :/ magic pathspec easier to discover for users. When the command is called from the root of the tree, there is no ambiguity and no need to change the behavior, hence no need to warn. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-26Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetchLibravatar Junio C Hamano1-0/+5
* jk/maint-gc-auto-after-fetch: fetch-pack: avoid repeatedly re-scanning pack directory fetch: run gc --auto after fetching
2013-01-26fetch-pack: avoid repeatedly re-scanning pack directoryLibravatar Jeff King1-0/+3
When we look up a sha1 object for reading via parse_object() => read_sha1_file() => read_object() callpath, we first check packfiles, and then loose objects. If we still haven't found it, we re-scan the list of packfiles in `objects/pack`. This final step ensures that we can co-exist with a simultaneous repack process which creates a new pack and then prunes the old object. This extra re-scan usually does not have a performance impact for two reasons: 1. If an object is missing, then typically the re-scan will find a new pack, then no more misses will occur. Or if it truly is missing, then our next step is usually to die(). 2. Re-scanning is cheap enough that we do not even notice. However, these do not always hold. The assumption in (1) is that the caller is expecting to find the object. This is usually the case, but the call to `parse_object` in `everything_local` does not follow this pattern. It is looking to see whether we have objects that the remote side is advertising, not something we expect to have. Therefore if we are fetching from a remote which has many refs pointing to objects we do not have, we may end up re-scanning the pack directory many times. Even with this extra re-scanning, the impact is often not noticeable due to (2); we just readdir() the packs directory and skip any packs that are already loaded. However, if there are a large number of packs, even enumerating the directory can be expensive, especially if we do it repeatedly. Having this many packs is a good sign the user should run `git gc`, but it would still be nice to avoid having to scan the directory at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-26fetch: run gc --auto after fetchingLibravatar Jeff King1-0/+5
We generally try to run "gc --auto" after any commands that might introduce a large number of new objects. An obvious place to do so is after running "fetch", which may introduce new loose objects or packs (depending on the size of the fetch). While an active developer repository will probably eventually trigger a "gc --auto" on another action (e.g., git-rebase), there are two good reasons why it is nicer to do it at fetch time: 1. Read-only repositories which track an upstream (e.g., a continuous integration server which fetches and builds, but never makes new commits) will accrue loose objects and small packs, but never coalesce them into a more efficient larger pack. 2. Fetching is often already perceived to be slow to the user, since they have to wait on the network. It's much more pleasant to include a potentially slow auto-gc as part of the already-long network fetch than in the middle of productive work with git-rebase or similar. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-26logmsg_reencode: lazily load missing commit buffersLibravatar Jeff King1-13/+0
Usually a commit that makes it to logmsg_reencode will have been parsed, and the commit->buffer struct member will be valid. However, some code paths will free commit buffers after having used them (for example, the log traversal machinery will do so to keep memory usage down). Most of the time this is fine; log should only show a commit once, and then exits. However, there are some code paths where this does not work. At least two are known: 1. A commit may be shown as part of a regular ref, and then it may be shown again as part of a submodule diff (e.g., if a repo contains refs to both the superproject and subproject). 2. A notes-cache commit may be shown during "log --all", and then later used to access a textconv cache during a diff. Lazily loading in logmsg_reencode does not necessarily catch all such cases, but it should catch most of them. Users of the commit buffer tend to be either parsing for structure (in which they will call parse_commit, and either we will already have parsed, or we will load commit->buffer lazily there), or outputting (either to the user, or fetching a part of the commit message via format_commit_message). In the latter case, we should always be using logmsg_reencode anyway (and typically we do so via the pretty-print machinery). If there are any cases that this misses, we can fix them up to use logmsg_reencode (or handle them on a case-by-case basis if that is inappropriate). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-26logmsg_reencode: never return NULLLibravatar Jeff King2-17/+6
The logmsg_reencode function will return the reencoded commit buffer, or NULL if reencoding failed or no reencoding was necessary. Since every caller then ends up checking for NULL and just using the commit's original buffer, anyway, we can be a bit more helpful and just return that buffer when we would have returned NULL. Since the resulting string may or may not need to be freed, we introduce a logmsg_free, which checks whether the buffer came from the commit object or not (callers either implemented the same check already, or kept two separate pointers, one to mark the buffer to be used, and one for the to-be-freed string). Pushing this logic into logmsg_* simplifies the callers, and will let future patches lazily load the commit buffer in a single place. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-26commit: drop useless xstrdup of commit messageLibravatar Jeff King1-1/+1
When git-commit is asked to reuse a commit message via "-c", we call read_commit_message, which looks up the commit and hands back either the re-encoded result, or a copy of the original. We make a copy in the latter case so that the ownership semantics of the return value are clear (in either case, it can be freed). However, since we return a "const char *", and since the resulting buffer's lifetime is the same as that of the whole program, we never bother to free it at all. Let's just drop the copy. That saves us a copy in the common case. While it does mean we leak in the re-encode case, it doesn't matter, since we are relying on program exit to free the memory anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24push: finishing touches to explain REJECT_ALREADY_EXISTS betterLibravatar Junio C Hamano1-2/+1
Now that "already exists" errors are given only when a push tries to update an existing ref in refs/tags/ hierarchy, we can say "the tag", instead of "the destination reference", and that is far easier to understand. Pointed out by Chris Rorvick. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCELibravatar Junio C Hamano2-0/+40
When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23Merge branch 'as/pre-push-hook'Libravatar Junio C Hamano3-18/+14
Add an extra hook so that "git push" that is run without making sure what is being pushed is sane can be checked and rejected (as opposed to the user deciding not pushing). * as/pre-push-hook: Add sample pre-push hook script push: Add support for pre-push hooks hooks: Add function to check if a hook exists
2013-01-23Merge branch 'as/check-ignore'Libravatar Junio C Hamano4-66/+205
Add a new command "git check-ignore" for debugging .gitignore files. The variable names may want to get cleaned up but that can be done in-tree. * as/check-ignore: clean.c, ls-files.c: respect encapsulation of exclude_list_groups t0008: avoid brace expansion add git-check-ignore sub-command setup.c: document get_pathspec() add.c: extract new die_if_path_beyond_symlink() for reuse add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse pathspec.c: rename newly public functions for clarity add.c: move pathspec matchers into new pathspec.c for reuse add.c: remove unused argument from validate_pathspec() dir.c: improve docs for match_pathspec() and match_pathspec_depth() dir.c: provide clear_directory() for reclaiming dir_struct memory dir.c: keep track of where patterns came from dir.c: use a single struct exclude_list per source of excludes Conflicts: builtin/ls-files.c dir.c
2013-01-23reflog: use parse_config_key in config callbackLibravatar Jeff King1-6/+7
This doesn't save any lines, but does keep us from doing error-prone pointer arithmetic with constants. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23help: use parse_config_key for man configLibravatar Jeff King1-7/+7
The resulting code ends up about the same length, but it is a little more self-explanatory. It now explicitly documents and checks the pre-condition that the incoming var starts with "man.", and drops the magic offset "4". Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-22Merge branch 'mz/reset-misc'Libravatar Junio C Hamano1-155/+132
Various 'reset' optimizations and clean-ups, followed by a change to allow "git reset" to work even on an unborn branch. * mz/reset-misc: reset: update documentation to require only tree-ish with paths reset [--mixed]: use diff-based reset whether or not pathspec was given reset: allow reset on unborn branch reset $sha1 $pathspec: require $sha1 only to be treeish reset.c: inline update_index_refresh() reset.c: finish entire cmd_reset() whether or not pathspec is given reset [--mixed]: only write index file once reset.c: move lock, write and commit out of update_index_refresh() reset.c: move update_index_refresh() call out of read_from_tree() reset.c: replace switch by if-else reset: avoid redundant error message reset --keep: only write index file once reset.c: share call to die_if_unmerged_cache() reset.c: extract function for updating {ORIG_,}HEAD reset.c: remove unnecessary variable 'i' reset.c: extract function for parsing arguments reset: don't allow "git reset -- $pathspec" in bare repo reset.c: pass pathspec around instead of (prefix, argv) pair reset $pathspec: exit with code 0 if successful reset $pathspec: no need to discard index
2013-01-21Merge branch 'zk/clean-report-failure'Libravatar Junio C Hamano1-29/+125
"git clean" states what it is going to remove and then goes on to remove it, but sometimes it only discovers things that cannot be removed after recursing into a directory, which makes the output confusing and even wrong. * zk/clean-report-failure: git-clean: Display more accurate delete messages
2013-01-21Merge branch 'nd/clone-no-separate-git-dir-with-bare'Libravatar Junio C Hamano1-0/+2
Forbid a useless combination of options to "git clone". * nd/clone-no-separate-git-dir-with-bare: clone: forbid --bare --separate-git-dir <dir>
2013-01-21grep: avoid accepting ambiguous revisionLibravatar Nguyễn Thái Ngọc Duy1-0/+2
Unlike other commands that take both revs and pathspecs without "--" disamiguators only when the boundary is clear, "git grep" treated what can be interpreted as a rev as-is, without making sure that it could also have meant a pathspec. E.g. $ git grep -e foo master when 'master' is in the working tree, should have triggered an ambiguity error, but it didn't, and searched in the tree of the commit named by 'master'. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>