summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-03-10Merge branch 'jc/am-i-v-fix' into maintLibravatar Junio C Hamano3-9/+15
The "v(iew)" subcommand of the interactive "git am -i" command was broken in 2.6.0 timeframe when the command was rewritten in C. * jc/am-i-v-fix: am -i: fix "v"iew pager: factor out a helper to prepare a child process to run the pager pager: lose a separate argv[]
2016-03-10Merge branch 'nd/git-common-dir-fix' into maintLibravatar Junio C Hamano2-1/+12
"git rev-parse --git-common-dir" used in the worktree feature misbehaved when run from a subdirectory. * nd/git-common-dir-fix: rev-parse: take prefix into account in --git-common-dir
2016-03-10Merge branch 'nd/dwim-wildcards-as-pathspecs' into maintLibravatar Junio C Hamano5-33/+54
"git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a rev, i.e. the object named by the the pathname with wildcard characters in a tree object. * nd/dwim-wildcards-as-pathspecs: get_sha1: don't die() on bogus search strings check_filename: tighten dwim-wildcard ambiguity checkout: reorder check_filename conditional
2016-03-10Merge branch 'jk/epipe-in-async' into maintLibravatar Junio C Hamano6-3/+25
Handling of errors while writing into our internal asynchronous process has been made more robust, which reduces flakiness in our tests. * jk/epipe-in-async: t5504: handle expected output from SIGPIPE death test_must_fail: report number of unexpected signal fetch-pack: ignore SIGPIPE in sideband demuxer write_or_die: handle EPIPE in async threads
2016-03-10Merge branch 'ps/config-error' into maintLibravatar Junio C Hamano13-105/+159
Many codepaths forget to check return value from git_config_set(); the function is made to die() to make sure we do not proceed when setting a configuration variable failed. * ps/config-error: config: rename git_config_set_or_die to git_config_set config: rename git_config_set to git_config_set_gently compat: die when unable to set core.precomposeunicode sequencer: die on config error when saving replay opts init-db: die on config errors when initializing empty repo clone: die on config error in cmd_clone remote: die on config error when manipulating remotes remote: die on config error when setting/adding branches remote: die on config error when setting URL submodule--helper: die on config error when cloning module submodule: die on config error when linking modules branch: die on config error when editing branch description branch: die on config error when unsetting upstream branch: report errors in tracking branch setup config: introduce set_or_die wrappers
2016-03-10Merge branch 'mg/work-tree-tests' into maintLibravatar Junio C Hamano3-0/+0
Traditionally, the tests that try commands that work on the contents in the working tree were named with "worktree" in their filenames, but with the recent addition of "git worktree" subcommand, whose tests are also named similarly, it has become harder to tell them apart. The traditional tests have been renamed to use "work-tree" instead in an attempt to differentiate them. * mg/work-tree-tests: tests: rename work-tree tests to *work-tree*
2016-03-10Merge branch 'sp/remote-curl-ssl-strerror' into maintLibravatar Junio C Hamano1-2/+14
Help those who debug http(s) part of the system. * sp/remote-curl-ssl-strerror: remote-curl: include curl_errorstr on SSL setup failures
2016-02-25t5504: handle expected output from SIGPIPE deathLibravatar Jeff King1-1/+4
Commit 8bf4bec (add "ok=sigpipe" to test_must_fail and use it to fix flaky tests, 2015-11-27) taught t5504 to handle "git push" racily exiting with SIGPIPE rather than failing. However, one of the tests checks the output of the command, as well. In the SIGPIPE case, we will not have produced any output. If we want the test to be truly non-flaky, we have to accept either output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25test_must_fail: report number of unexpected signalLibravatar Jeff King1-1/+1
If a command is marked as test_must_fail but dies with a signal, we consider that a problem and report the error to stderr. However, we don't say _which_ signal; knowing that can make debugging easier. Let's share as much as we know. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25fetch-pack: ignore SIGPIPE in sideband demuxerLibravatar Jeff King1-1/+5
If the other side feeds us a bogus pack, index-pack (or unpack-objects) may die early, before consuming all of its input. As a result, the sideband demuxer may get SIGPIPE (racily, depending on whether our data made it into the pipe buffer or not). If this happens and we are compiled with pthread support, it will take down the main thread, too. This isn't the end of the world, as the main process will just die() anyway when it sees index-pack failed. But it does mean we don't get a chance to say "fatal: index-pack failed" or similar. And it also means that we racily fail t5504, as we sometimes die() and sometimes are killed by SIGPIPE. So let's ignore SIGPIPE while demuxing the sideband. We are already careful to check the return value of write(), so we won't waste time writing to a broken pipe. The caller will notice the error return from the async thread, though in practice we don't even get that far, as we die() as soon as we see that index-pack failed. The non-sideband case is already fine; we let index-pack read straight from the socket, so there is no SIGPIPE at all. Technically the non-threaded async case is also OK without this (the forked async process gets SIGPIPE), but it's not worth distinguishing from the threaded case here. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25write_or_die: handle EPIPE in async threadsLibravatar Jeff King3-0/+15
When write_or_die() sees EPIPE, it treats it specially by converting it into a SIGPIPE death. We obviously cannot ignore it, as the write has failed and the caller expects us to die. But likewise, we cannot just call die(), because printing any message at all would be a nuisance during normal operations. However, this is a problem if write_or_die() is called from a thread. Our raised signal ends up killing the whole process, when logically we just need to kill the thread (after all, if we are ignoring SIGPIPE, there is good reason to think that the main thread is expecting to handle it). Inside an async thread, the die() code already does the right thing, because we use our custom die_async() routine, which calls pthread_join(). So ideally we would piggy-back on that, and simply call: die_quietly_with_code(141); or similar. But refactoring the die code to do this is surprisingly non-trivial. The die_routines themselves handle both printing and the decision of the exit code. Every one of them would have to be modified to take new parameters for the code, and to tell us to be quiet. Instead, we can just teach write_or_die() to check for the async case and handle it specially. We do have to build an interface to abstract the async exit, but it's simple and self-contained. If we had many call-sites that wanted to do this die_quietly_with_code(), this approach wouldn't scale as well, but we don't. This is the only place where do this weird exit trick. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22Git 2.7.2Libravatar Junio C Hamano3-2/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22Merge branch 'nd/ita-cleanup' into maintLibravatar Junio C Hamano6-10/+6
Paths that have been told the index about with "add -N" are not quite yet in the index, but a few commands behaved as if they already are in a harmful way. * nd/ita-cleanup: grep: make it clear i-t-a entries are ignored add and use a convenience macro ce_intent_to_add() blame: remove obsolete comment
2016-02-22Merge branch 'pw/completion-stash' into maintLibravatar Junio C Hamano1-2/+2
* pw/completion-stash: completion: fix mis-indentation in _git_stash()
2016-02-22Merge branch 'mm/clean-doc-fix' into maintLibravatar Junio C Hamano1-3/+1
The documentation for "git clean" has been corrected; it mentioned that .git/modules/* are removed by giving two "-f", which has never been the case. * mm/clean-doc-fix: Documentation/git-clean.txt: don't mention deletion of .git/modules/*
2016-02-22Merge branch 'dw/mergetool-vim-window-shuffle' into maintLibravatar Junio C Hamano1-2/+2
The vimdiff backend for "git mergetool" has been tweaked to arrange and number buffers in the order that would match the expectation of majority of people who read left to right, then top down and assign buffers 1 2 3 4 "mentally" to local base remote merge windows based on that order. * dw/mergetool-vim-window-shuffle: mergetool: reorder vim/gvim buffers in three-way diffs
2016-02-22Merge branch 'ah/stripspace-optstring' into maintLibravatar Junio C Hamano1-1/+1
* ah/stripspace-optstring: stripspace: call U+0020 a "space" instead of a "blank"
2016-02-22completion: fix mis-indentation in _git_stash()Libravatar SZEDER Gábor1-2/+2
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22config: rename git_config_set_or_die to git_config_setLibravatar Patrick Steinhardt10-67/+67
Rename git_config_set_or_die functions to git_config_set, leading to the new default behavior of dying whenever a configuration error occurs. By now all callers that shall die on error have been transitioned to the _or_die variants, thus making this patch a simple rename of the functions. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22config: rename git_config_set to git_config_set_gentlyLibravatar Patrick Steinhardt7-39/+40
The desired default behavior for `git_config_set` is to die whenever an error occurs. Dying is the default for a lot of internal functions when failures occur and is in this case the right thing to do for most callers as otherwise we might run into inconsistent repositories without noticing. As some code may rely on the actual return values for `git_config_set` we still require the ability to invoke these functions without aborting. Rename the existing `git_config_set` functions to `git_config_set_gently` to keep them available for those callers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22compat: die when unable to set core.precomposeunicodeLibravatar Patrick Steinhardt1-1/+2
When calling `git_config_set` to set 'core.precomposeunicode' we ignore the return value of the function, which may indicate that we were unable to write the value back to disk. As the function is only called by init-db we can and should die when an error occurs. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22sequencer: die on config error when saving replay optsLibravatar Patrick Steinhardt1-11/+11
When we start picking a range of revisions we save the replay options that are required to restore state when interrupting and later continuing picking the revisions. However, we do not check the return values of the `git_config_set` functions, which may lead us to store incomplete information. As this may lead us to fail when trying to continue the sequence the error can be fatal. Fix this by dying immediately when we are unable to write back any replay option. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22init-db: die on config errors when initializing empty repoLibravatar Patrick Steinhardt1-10/+10
When creating an empty repository with `git init-db` we do not check for error codes returned by `git_config_set` functions. This may cause the user to end up with an inconsistent repository without any indication for the user. Fix this problem by dying early with an error message when we are unable to write the configuration files to disk. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22clone: die on config error in cmd_cloneLibravatar Patrick Steinhardt1-4/+4
The clone command does not check for error codes returned by `git_config_set` functions. This may cause the user to end up with an inconsistent repository without any indication with what went wrong. Fix this problem by dying with an error message when we are unable to write the configuration files to disk. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22remote: die on config error when manipulating remotesLibravatar Patrick Steinhardt1-27/+12
When manipulating remotes we try to set various configuration values without checking if the values were persisted correctly, possibly leaving the remote in an inconsistent state. Fix this issue by dying early and notifying the user about the error. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22remote: die on config error when setting/adding branchesLibravatar Patrick Steinhardt1-17/+9
When we add or set new branches (e.g. by `git remote add -f` or `git remote set-branches`) we do not check for error codes when writing the branches to the configuration file. When persisting the configuration failed we are left with a remote that has none or not all of the branches that should have been set without notifying the user. Fix this issue by dying early on configuration error. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22remote: die on config error when setting URLLibravatar Patrick Steinhardt2-5/+15
When invoking `git-remote --set-url` we do not check the return value when writing the actual new URL to the configuration file, pretending to the user that the configuration has been set while it was in fact not persisted. Fix this problem by dying early when setting the config fails. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22submodule--helper: die on config error when cloning moduleLibravatar Patrick Steinhardt1-2/+2
When setting the 'core.worktree' option for a newly cloned submodule we ignore the return value of `git_config_set_in_file`. As this leaves the submodule in an inconsistent state, we instead want to inform the user that something has gone wrong by printing an error and aborting the program. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22submodule: die on config error when linking modulesLibravatar Patrick Steinhardt1-5/+3
When trying to connect a submodule with its corresponding repository in '.git/modules' we try to set the core.worktree setting in the submodule, which may fail due to an error encountered in `git_config_set_in_file`. The function is used in the git-mv command when trying to move a submodule to another location. We already die when renaming a file fails but do not pay attention to the case where updating the connection between submodule and its repository fails. As this leaves the repository in an inconsistent state, as well, abort the program by dying early and presenting the failure to the user. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22branch: die on config error when editing branch descriptionLibravatar Patrick Steinhardt1-3/+2
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22branch: die on config error when unsetting upstreamLibravatar Patrick Steinhardt2-2/+9
When we try to unset upstream configurations we do not check return codes for the `git_config_set` functions. As those may indicate that we were unable to unset the respective configuration we may exit successfully without any error message while in fact the upstream configuration was not unset. Fix this by dying with an error message when we cannot unset the configuration. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22branch: report errors in tracking branch setupLibravatar Patrick Steinhardt3-16/+46
When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-20tests: rename work-tree tests to *work-tree*Libravatar Michael J Gruber3-0/+0
"Work tree" or "working tree" is the name of a checked out tree, "worktree" the name of the command which manages several working trees. The naming of tests mixes these two, currently: $ls t/*worktree* t/t1501-worktree.sh t/t1509-root-worktree.sh t/t2025-worktree-add.sh t/t2026-worktree-prune.sh t/t2027-worktree-list.sh t/t2104-update-index-skip-worktree.sh t/t3320-notes-merge-worktrees.sh t/t7011-skip-worktree-reading.sh t/t7012-skip-worktree-writing.sh t/t7409-submodule-detached-worktree.sh $grep -l "git worktree" t/*.sh t/t0002-gitfile.sh t/t1400-update-ref.sh t/t2025-worktree-add.sh t/t2026-worktree-prune.sh t/t2027-worktree-list.sh t/t3320-notes-merge-worktrees.sh t/t7410-submodule-checkout-to.sh Rename t1501, t1509 and t7409 to make it clear on first glance that they test work tree related behavior, rather than the worktree command. t2104, t7011 and t7012 are about the "skip-worktree" flag so that their name should remain unchanged. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17Start preparing for 2.7.2Libravatar Junio C Hamano2-1/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17Merge branch 'js/test-lib-windows-emulated-yes' into maintLibravatar Junio C Hamano1-2/+4
The emulated "yes" command used in our test scripts has been tweaked not to spend too much time generating unnecessary output that is not used, to help those who test on Windows where it would not stop until it fills the pipe buffer due to lack of SIGPIPE. * js/test-lib-windows-emulated-yes: test-lib: limit the output of the yes utility
2016-02-17Merge branch 'aw/push-force-with-lease-reporting' into maintLibravatar Junio C Hamano2-12/+18
"git push --force-with-lease" has been taught to report if the push needed to force (or fast-forwarded). * aw/push-force-with-lease-reporting: push: fix ref status reporting for --force-with-lease
2016-02-17Merge branch 'nd/do-not-move-worktree-manually' into maintLibravatar Junio C Hamano3-21/+14
"git worktree" had a broken code that attempted to auto-fix possible inconsistency that results from end-users moving a worktree to different places without telling Git (the original repository needs to maintain backpointers to its worktrees, but "mv" run by end-users who are not familiar with that fact will obviously not adjust them), which actually made things worse when triggered. * nd/do-not-move-worktree-manually: worktree: stop supporting moving worktrees manually worktree.c: fix indentation
2016-02-17Merge branch 'js/xmerge-marker-eol' into maintLibravatar Junio C Hamano2-18/+93
The low-level merge machinery has been taught to use CRLF line termination when inserting conflict markers to merged contents that are themselves CRLF line-terminated. * js/xmerge-marker-eol: merge-file: ensure that conflict sections match eol style merge-file: let conflict markers match end-of-line style of the context
2016-02-17git-cvsserver.perl: fix typoLibravatar GyuYong Jung1-1/+1
Signed-off-by: GyuYong Jung <obliviscence@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17am -i: fix "v"iewLibravatar Junio C Hamano1-1/+1
The 'v'iew subcommand of the interactive mode of "git am -i" was broken by the rewrite to C we did at around 2.6.0 timeframe at 7ff26832 (builtin-am: implement -i/--interactive, 2015-08-04); we used to spawn the pager via the shell, accepting things like PAGER='less -S' in the environment, but the rewrite forgot and tried to directly spawn a command whose name is the entire string. The previous refactoring of the new helper function makes it easier for us to do the right thing. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17pager: factor out a helper to prepare a child process to run the pagerLibravatar Junio C Hamano2-6/+14
When running a pager, we need to run the program git_pager() gave us, but we need to make sure we spawn it via the shell (i.e. it is valid to say PAGER='less -S', for example) and give default values to $LESS and $LV environment variables. Factor out these details to a separate helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-16pager: lose a separate argv[]Libravatar Junio C Hamano1-3/+1
These days, using the embedded args array in the child_process structure is the norm. Follow that practice. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-16config: introduce set_or_die wrappersLibravatar Patrick Steinhardt2-0/+31
A lot of call-sites for the existing family of `git_config_set` functions do not check for errors that may occur, e.g. when the configuration file is locked. In many cases we simply want to die when such a situation arises. Introduce wrappers that will cause the program to die in those cases. These wrappers are temporary only to ease the transition to let `git_config_set` die by default. They will be removed later on when `git_config_set` itself has been replaced by `git_config_set_gently`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-15remote-curl: include curl_errorstr on SSL setup failuresLibravatar Shawn Pearce1-2/+14
For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the additional text stored in CURLOPT_ERRORBUFFER to debug why the connection did not start. This is curl_errorstr inside of http.c, so include that in the message if it is non-empty. Sometimes HTTP response codes aren't yet available, such as when the SSL setup fails. Don't include HTTP 0 in the message. Signed-off-by: Shawn Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-12rev-parse: take prefix into account in --git-common-dirLibravatar Nguyễn Thái Ngọc Duy2-1/+12
Most of the time, get_git_common_dir() returns an absolute path so prefix is irrelevant. If it returns a relative path (e.g. from the main worktree) then prefixing is required. Noticed-by: Mike Hommey <mh@glandium.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-12mergetool: reorder vim/gvim buffers in three-way diffsLibravatar Dickson Wong1-2/+2
When invoking default (g)vimdiff three-way merge, the merged file is loaded as the first buffer but moved to the bottom as the fourth window. This causes a disconnect between vim commands that operate on window positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g. do/dp). This change reorders the buffers to have the same index as windows while keeping the cursor default to the merged result as the bottom window. Signed-off-by: Dickson Wong <dicksonwong@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Acked-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-10get_sha1: don't die() on bogus search stringsLibravatar Jeff King2-2/+12
The get_sha1() function generally returns an error code rather than dying, and we sometimes speculatively call it with something that may be a revision or a pathspec, in order to see which one it might be. If it sees a bogus ":/" search string, though, it complains, without giving the caller the opportunity to recover. We can demonstrate this in t6133 by looking for ":/*.t", which should mean "*.t at the root of the tree", but instead dies because of the invalid regex (the "*" has nothing to operate on). We can fix this by returning an error rather than calling die(). Unfortunately, the tradeoff is that the error message is slightly worse in cases where we _do_ know we have a rev. E.g., running "git log ':/*.t' --" before yielded: fatal: Invalid search pattern: *.t and now we get only: fatal: bad revision ':/*.t' There's not a simple way to fix this short of passing a "quiet" flag all the way through the get_sha1() stack. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-10check_filename: tighten dwim-wildcard ambiguityLibravatar Jeff King4-31/+42
When specifying both revisions and pathnames, we allow "<rev> -- <pathspec>" to be spelled without the "--" as long as it is not ambiguous. The original logic was something like: 1. Resolve each item with get_sha1(). If successful, we know it can be a <rev>. Verify that it _isn't_ a filename, using verify_non_filename(), and complain of ambiguity otherwise. 2. If get_sha1() didn't succeed, make sure that it _is_ a file, using verify_filename(). If not, complain that it is neither a <rev> nor a <pathspec>. Both verify_filename() and verify_non_filename() rely on check_filename(), which definitely said "yes, this is a file" or "no, it is not" using lstat(). Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used, 2015-05-02) introduced a convenience feature: check_filename() will consider anything with wildcard meta-characters as a possible filename, without even checking the filesystem. This works well for case 2. For such a wildcard, we would previously have died and said "it is neither". Post-28fcc0b, we assume it's a pathspec and proceed. But it makes some instances of case 1 worse. We may have an extended sha1 expression that contains meta-characters (e.g., "HEAD^{/foo.*bar}"), and we now complain that it's also a filename, due to the wildcard characters (even though that wildcard would not match anything in the filesystem). One solution would be to actually expand the pathname and see if it matches anything on the filesystem. But that's potentially expensive, and we do not have to be so rigorous for this DWIM magic (if you want rigor, use "--"). Instead, we can just use different rules for cases 1 and 2. When we know something is a rev, we will complain only if it meets a much higher standard for "this is also a file"; namely that it actually exists in the filesystem. Case 2 remains the same: we use the looser "it could be a filename" standard introduced by 28fcc0b. We can accomplish this by pulling the wildcard logic out of check_filename() and putting it into verify_filename(). Its partner verify_non_filename() does not need a change, since check_filename() goes back to implementing the "higher standard". Besides these two callers of check_filename(), there is one other: git-checkout does a similar DWIM itself. It hits this code path only after get_sha1() has returned failure, making it case 2, which gets the special wildcard treatment. Note that we drop the tests in t2019 in favor of a more complete set in t6133. t2019 was not the right place for them (it's about refname ambiguity, not dwim parsing ambiguity), and the second test explicitly checked for the opposite result of the case we are fixing here (which didn't really make any sense; as shown by the test_must_fail in the test, it would only serve to annoy people). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-10checkout: reorder check_filename conditionalLibravatar Jeff King1-1/+1
If we have a "--" flag, we should not be doing DWIM magic based on whether arguments can be filenames. Reorder the conditional to avoid the check_filename() call entirely in this case. The outcome is the same, but the short-circuit makes the dependency more clear. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-09Documentation/git-clean.txt: don't mention deletion of .git/modules/*Libravatar Matt McCutchen1-3/+1
The latter half of this sentence, the removal of the submodules, was never done with (or without) double -f back when it was written, and we still do not do so. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>