summaryrefslogtreecommitdiff
path: root/setup.c
AgeCommit message (Collapse)AuthorFilesLines
2013-04-03Merge branch 'jk/alias-in-bare' into maintLibravatar Junio C Hamano1-2/+10
An aliased command spawned from a bare repository that does not say it is bare with "core.bare = yes" is treated as non-bare by mistake. * jk/alias-in-bare: setup: suppress implicit "." work-tree for bare repos environment: add GIT_PREFIX to local_repo_env cache.h: drop LOCAL_REPO_ENV_SIZE
2013-04-03Merge branch 'lf/setup-prefix-pathspec' into maintLibravatar Junio C Hamano1-5/+7
"git cmd -- ':(top'" was not diagnosed as an invalid syntax, and instead the parser kept reading beyond the end of the string. * lf/setup-prefix-pathspec: setup.c: check that the pathspec magic ends with ")" setup.c: stop prefix_pathspec() from looping past the end of string
2013-03-14setup.c: check that the pathspec magic ends with ")"Libravatar Andrew Wong1-2/+3
The previous code did not diagnose an incorrectly spelled ":(top" as an error. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-14setup.c: stop prefix_pathspec() from looping past the end of stringLibravatar Andrew Wong1-3/+4
The code assumes that the string ends at either `)` or `,`, and does not handle the case where strcspn() returns length due to end of string. So specifying ":(top" as pathspec will cause the loop to go past the end of string. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08setup: suppress implicit "." work-tree for bare reposLibravatar Jeff King1-0/+8
If an explicit GIT_DIR is given without a working tree, we implicitly assume that the current working directory should be used as the working tree. E.g.,: GIT_DIR=/some/repo.git git status would compare against the cwd. Unfortunately, we fool this rule for sub-invocations of git by setting GIT_DIR internally ourselves. For example: git init foo cd foo/.git git status ;# fails, as we expect git config alias.st status git status ;# does not fail, but should What happens is that we run setup_git_directory when doing alias lookup (since we need to see the config), set GIT_DIR as a result, and then leave GIT_WORK_TREE blank (because we do not have one). Then when we actually run the status command, we do setup_git_directory again, which sees our explicit GIT_DIR and uses the cwd as an implicit worktree. It's tempting to argue that we should be suppressing that second invocation of setup_git_directory, as it could use the values we already found in memory. However, the problem still exists for sub-processes (e.g., if "git status" were an external command). You can see another example with the "--bare" option, which sets GIT_DIR explicitly. For example: git init foo cd foo/.git git status ;# fails git --bare status ;# does NOT fail We need some way of telling sub-processes "even though GIT_DIR is set, do not use cwd as an implicit working tree". We could do it by putting a special token into GIT_WORK_TREE, but the obvious choice (an empty string) has some portability problems. Instead, we add a new boolean variable, GIT_IMPLICIT_WORK_TREE, which suppresses the use of cwd as a working tree when GIT_DIR is set. We trigger the new variable when we know we are in a bare setting. The variable is left intentionally undocumented, as this is an internal detail (for now, anyway). If somebody comes up with a good alternate use for it, and once we are confident we have shaken any bugs out of it, we can consider promoting it further. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08environment: add GIT_PREFIX to local_repo_envLibravatar Jeff King1-2/+2
The GIT_PREFIX variable is set based on our location within the working tree. It should therefore be cleared whenever GIT_WORK_TREE is cleared. In practice, this doesn't cause any bugs, because none of the sub-programs we invoke with local_repo_env cleared actually care about GIT_PREFIX. But this is the right thing to do, and future proofs us against that assumption changing. While we're at it, let's define a GIT_PREFIX_ENVIRONMENT macro; this avoids repetition of the string literal, which can help catch any spelling mistakes in the code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-27Merge branch 'mh/maint-ceil-absolute'Libravatar Junio C Hamano1-10/+22
An earlier workaround designed to help people who list logical directories that will not match what getcwd(3) returns in the GIT_CEILING_DIRECTORIES had an adverse effect when it is slow to stat and readlink a directory component of an element listed on it. * mh/maint-ceil-absolute: Provide a mechanism to turn off symlink resolution in ceiling paths
2013-02-22Provide a mechanism to turn off symlink resolution in ceiling pathsLibravatar Michael Haggerty1-10/+22
Commit 1b77d83cab 'setup_git_directory_gently_1(): resolve symlinks in ceiling paths' changed the setup code to resolve symlinks in the entries in GIT_CEILING_DIRECTORIES. Because those entries are compared textually to the symlink-resolved current directory, an entry in GIT_CEILING_DIRECTORIES that contained a symlink would have no effect. It was known that this could cause performance problems if the symlink resolution *itself* touched slow filesystems, but it was thought that such use cases would be unlikely. The intention of the earlier change was to deal with a case when the user has this: GIT_CEILING_DIRECTORIES=/home/gitster but in reality, /home/gitster is a symbolic link to somewhere else, e.g. /net/machine/home4/gitster. A textual comparison between the specified value /home/gitster and the location getcwd(3) returns would not help us, but readlink("/home/gitster") would still be fast. After this change was released, Anders Kaseorg <andersk@mit.edu> reported: > [...] my computer has been acting so slow when I’m not connected to > the network. I put various network filesystem paths in > $GIT_CEILING_DIRECTORIES, such as > /afs/athena.mit.edu/user/a/n/andersk (to avoid hitting its parents > /afs/athena.mit.edu, /afs/athena.mit.edu/user/a, and > /afs/athena.mit.edu/user/a/n which all live in different AFS > volumes). Now when I’m not connected to the network, every > invocation of Git, including the __git_ps1 in my shell prompt, waits > for AFS to timeout. To allow users to work around this problem, give them a mechanism to turn off symlink resolution in GIT_CEILING_DIRECTORIES entries. All the entries that follow an empty entry will not be checked for symbolic links and used literally in comparison. E.g. with these: GIT_CEILING_DIRECTORIES=:/foo/bar:/xyzzy or GIT_CEILING_DIRECTORIES=/foo/bar::/xyzzy we will not readlink("/xyzzy") because it comes after an empty entry. With the former (but not with the latter), "/foo/bar" comes after an empty entry, and we will not readlink it, either. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30Merge branch 'nd/magic-pathspec-from-root'Libravatar Junio C Hamano1-1/+8
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-23Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-0/+19
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-21Update :/abc ambiguity checkLibravatar Nguyễn Thái Ngọc Duy1-1/+8
:/abc may mean two things: - as a revision, it means the revision that has "abc" in commit message. - as a pathpec, it means "abc" from root. Currently we see ":/abc" as a rev (most of the time), but never see it as a pathspec even if "abc" exists and "git log :/abc" will gladly take ":/abc" as rev even it's ambiguous. This patch makes it: - ambiguous when "abc" exists on worktree - a rev if abc does not exist on worktree - a path if abc is not found in any commits (although better use "--" to avoid ambiguation because searching through commit DAG is expensive) A plus from this patch is, because ":/" never matches anything as a rev, it is never considered a valid rev and because root directory always exists, ":/" is always unambiguously seen as a pathspec. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-06setup.c: document get_pathspec()Libravatar Adam Spiers1-0/+19
Since we have just created a new pathspec-handling library, now is a good time to add some comments explaining get_pathspec(). Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-29setup_git_directory_gently_1(): resolve symlinks in ceiling pathsLibravatar Michael Haggerty1-13/+13
longest_ancestor_length() relies on a textual comparison of directory parts to find the part of path that overlaps with one of the paths in prefix_list. But this doesn't work if any of the prefixes involves a symbolic link, because the directories will look different even though they might logically refer to the same directory. So canonicalize the paths listed in GIT_CEILING_DIRECTORIES using real_path_if_valid() before passing them to longest_ancestor_length(). (Also rename normalize_ceiling_entry() to canonicalize_ceiling_entry() to reflect the change.) path is already in canonical form, so doesn't need to be canonicalized again. This fixes some problems with using GIT_CEILING_DIRECTORIES that contains paths involving symlinks, including t4035 if run with --root set to a path involving symlinks. Please note that test t0060 is *not* changed analogously, because that would make the test suite results dependent on the contents of the local root directory. However, real_path() is already tested independently, and the "ancestor" tests cover the non-normalization aspects of longest_ancestor_length(), so coverage remains sufficient. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net>
2012-10-29longest_ancestor_length(): require prefix list entries to be normalizedLibravatar Michael Haggerty1-0/+23
Move the responsibility for normalizing prefixes from longest_ancestor_length() to its callers. Use slightly different normalizations at the two callers: In setup_git_directory_gently_1(), use the old normalization, which ignores paths that are not usable. In the next commit we will change this caller to also resolve symlinks in the paths from GIT_CEILING_DIRECTORIES as part of the normalization. In "test-path-utils longest_ancestor_length", use the old normalization, but die() if any paths are unusable. Also change t0060 to only pass normalized paths to the test program (no empty entries or non-absolute paths, strip trailing slashes from the paths, and remove tests that thereby become redundant). The point of this change is to reduce the scope of the ancestor_length tests in t0060 from testing normalization+longest_prefix to testing only mostly longest_prefix. This is necessary because when setup_git_directory_gently_1() starts resolving symlinks as part of its normalization, it will not be reasonable to do the same in the test suite, because that would make the test results depend on the contents of the root directory of the filesystem on which the test is run. HOWEVER: under Windows, bash mangles arguments that look like absolute POSIX paths into DOS paths. So we have to retain the level of normalization done by normalize_path_copy() to convert the bash-mangled DOS paths (which contain backslashes) into paths that use forward slashes. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net>
2012-10-29longest_ancestor_length(): take a string_list argument for prefixesLibravatar Michael Haggerty1-2/+9
Change longest_ancestor_length() to take the prefixes argument as a string_list rather than as a colon-separated string. This will make it easier for the caller to alter the entries before calling longest_ancestor_length(). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net>
2012-09-10Merge branch 'maint-1.7.11' into maintLibravatar Junio C Hamano1-3/+5
* maint-1.7.11: Almost 1.7.11.6 gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO rebase -i: use full onto sha1 in reflog sh-setup: protect from exported IFS receive-pack: do not leak output from auto-gc to standard output t/t5400: demonstrate breakage caused by informational message from prune setup: clarify error messages for file/revisions ambiguity send-email: improve RFC2047 quote parsing 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-22Merge branch 'mm/die-with-dashdash-help'Libravatar Junio C Hamano1-3/+5
When the user gives an argument that can be taken as both a revision name and a pathname without disambiguating with "--", we used to give a help message "Use '--' to separate". The message has been clarified to show where that '--' goes on the command line. * mm/die-with-dashdash-help: setup: clarify error messages for file/revisions ambiguity
2012-08-03setup: clarify error messages for file/revisions ambiguityLibravatar Matthieu Moy1-3/+5
The previous "Use '--' to separate filenames from revisions" may sound obvious for an old-time Unix user, but does not make it clear how to use this '--'. In addition to mentionning this '--', give an idea of what the new command should look like. Ideally, we could provide cut-and-paste ready commands based on the command that just failed, but we have no easy access to argv[] in this place of the code. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Merge branch 'jc/sha1-name-more'Libravatar Junio C Hamano1-6/+2
Teaches the object name parser things like a "git describe" output is always a commit object, "A" in "git log A" must be a committish, and "A" and "B" in "git log A...B" both must be committish, etc., to prolong the lifetime of abbreviated object names. * jc/sha1-name-more: (27 commits) t1512: match the "other" object names t1512: ignore whitespaces in wc -l output rev-parse --disambiguate=<prefix> rev-parse: A and B in "rev-parse A..B" refer to committish reset: the command takes committish commit-tree: the command wants a tree and commits apply: --build-fake-ancestor expects blobs sha1_name.c: add support for disambiguating other types revision.c: the "log" family, except for "show", takes committish revision.c: allow handle_revision_arg() to take other flags sha1_name.c: introduce get_sha1_committish() sha1_name.c: teach lookup context to get_sha1_with_context() sha1_name.c: many short names can only be committish sha1_name.c: get_sha1_1() takes lookup flags sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags get_sha1(): fix error status regression sha1_name.c: restructure disambiguation of short names sha1_name.c: correct misnamed "canonical" and "res" ...
2012-07-11Merge branch 'th/diff-no-index-fixes' into maintLibravatar Junio C Hamano1-2/+22
"git diff --no-index" did not correctly handle relative paths and did not correctly give exit codes when run under "--quiet" option. * th/diff-no-index-fixes: diff-no-index: exit(1) if 'diff --quiet <repo file> <external file>' finds changes diff: handle relative paths in no-index
2012-07-11Merge branch 'mm/verify-filename-fix' into maintLibravatar Junio C Hamano1-3/+24
"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-04Merge branch 'th/diff-no-index-fixes'Libravatar Junio C Hamano1-2/+22
"git diff --no-index" did not correctly handle relative paths and did not give correct exit codes when run under "--quiet" option. * th/diff-no-index-fixes: diff-no-index: exit(1) if 'diff --quiet <repo file> <external file>' finds changes diff: handle relative paths in no-index
2012-07-03sha1_name.c: get rid of get_sha1_with_mode_1()Libravatar Junio C Hamano1-6/+2
The only external caller is setup.c that tries to give a nicer error message when an object name is misspelt (e.g. "HEAD:cashe.h"). Retire it and give the caller a dedicated and more intuitive API function maybe_die_on_misspelt_object_name(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-28Merge branch 'mm/verify-filename-fix'Libravatar Junio C Hamano1-3/+24
"git diff COPYING HEAD:COPYING" gave a nonsense error message that claimed that the treeish HEAD did not have COPYING in it.
2012-06-22diff: handle relative paths in no-indexLibravatar Jeff King1-2/+22
When diff-no-index is given a relative path to a file outside the repository, it aborts with error. However, if the file is given using an absolute path, the diff runs as expected. The two cases should be treated the same. Tests and commit message by Tim Henigan. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Tim Henigan <tim.henigan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-18verify_filename(): ask the caller to chose the kind of diagnosisLibravatar Matthieu Moy1-3/+24
verify_filename() can be called in two different contexts. Either we just tried to interpret a string as an object name, and it fails, so we try looking for a working tree file (i.e. we finished looking at revs that come earlier on the command line, and the next argument must be a pathname), or we _know_ that we are looking for a pathname, and shouldn't even try interpreting the string as an object name. For example, with this change, we get: $ git log COPYING HEAD:inexistant fatal: HEAD:inexistant: no such path in the working tree. Use '-- <path>...' to specify paths that do not exist locally. $ git log HEAD:inexistant fatal: Path 'inexistant' does not exist in 'HEAD' Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15properly keep track of current working directoryLibravatar Clemens Buchacher1-9/+13
Various failure modes in the repository detection code path currently quote the wrong directory in their error message. The working directory is changed iteratively to the parent directory until a git repository is found. If the working directory cannot be changed to the parent directory for some reason, the detection gives up and prints an error message. The error message should report the current working directory. Instead of continually updating the 'cwd' variable, which is actually used to remember the original working directory, the 'offset' variable is used to keep track of the current working directory. At the point where the affected error handling code is called, 'offset' already points to the end of the parent of the working directory, rather than the current working directory. Fix this by explicitly using a variable 'offset_parent' and update 'offset' concurrently with the call to chdir. In a similar fashion, the function get_device_or_die() would print the original working directory in case of a failure, rather than the current working directory. Fix this as well by making use of the 'offset' variable. Lastly, replace the phrase 'mount parent' with 'mount point'. The former appears to be a typo. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-02standardize and improve lookup rules for external local reposLibravatar Jeff King1-1/+1
When you specify a local repository on the command line of clone, ls-remote, upload-pack, receive-pack, or upload-archive, or in a request to git-daemon, we perform a little bit of lookup magic, doing things like looking in working trees for .git directories and appending ".git" for bare repos. For clone, this magic happens in get_repo_path. For everything else, it happens in enter_repo. In both cases, there are some ambiguous or confusing cases that aren't handled well, and there is one case that is not handled the same by both methods. This patch tries to provide (and test!) standard, sensible lookup rules for both code paths. The intended changes are: 1. When looking up "foo", we have always preferred a working tree "foo" (containing "foo/.git" over the bare "foo.git". But we did not prefer a bare "foo" over "foo.git". With this patch, we do so. 2. We would select directories that existed but didn't actually look like git repositories. With this patch, we make sure a selected directory looks like a git repo. Not only is this more sensible in general, but it will help anybody who is negatively affected by change (1) negatively (e.g., if they had "foo.git" next to its separate work tree "foo", and expect to keep finding "foo.git" when they reference "foo"). 3. The enter_repo code path would, given "foo", look for "foo.git/.git" (i.e., do the ".git" append magic even for a repo with working tree). The clone code path did not; with this patch, they now behave the same. In the unlikely case of a working tree overlaying a bare repo (i.e., a ".git" directory _inside_ a bare repo), we continue to treat it as a working tree (prefering the "inner" .git over the bare repo). This is mainly because the combination seems nonsensical, and I'd rather stick with existing behavior on the off chance that somebody is relying on it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10Merge branch 'cb/common-prefix-unification'Libravatar Junio C Hamano1-32/+0
* cb/common-prefix-unification: rename pathspec_prefix() to common_prefix() and move to dir.[ch] consolidate pathspec_prefix and common_prefix remove prefix argument from pathspec_prefix
2011-10-10Merge branch 'fg/submodule-git-file-git-dir'Libravatar Junio C Hamano1-0/+7
* fg/submodule-git-file-git-dir: Move git-dir for submodules rev-parse: add option --resolve-git-dir <path> Conflicts: cache.h git-submodule.sh
2011-09-12rename pathspec_prefix() to common_prefix() and move to dir.[ch]Libravatar Clemens Buchacher1-7/+0
Also make common_prefix_len() static as this refactoring makes dir.c itself the only caller of this helper function. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-06consolidate pathspec_prefix and common_prefixLibravatar Junio C Hamano1-27/+2
The implementation from pathspec_prefix (slightly modified) replaces the current common_prefix, because it also respects glob characters. Based on a patch by Clemens Buchacher. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-06remove prefix argument from pathspec_prefixLibravatar Clemens Buchacher1-2/+2
Passing a prefix to a function that is supposed to find the prefix is strange. And it's really only used if the pathspec is NULL. Make the callers handle this case instead. As we are always returning a fresh copy of a string (or NULL), change the type of the returned value to non-const "char *". Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28Merge branch 'nd/maint-clone-gitdir'Libravatar Junio C Hamano1-3/+3
* nd/maint-clone-gitdir: clone: allow to clone from .git file read_gitfile_gently(): rename misnamed function to read_gitfile()
2011-08-25Merge branch 'di/parse-options-split'Libravatar Junio C Hamano1-28/+0
* di/parse-options-split: Reduce parse-options.o dependencies parse-options: export opterr, optbug
2011-08-22read_gitfile_gently(): rename misnamed function to read_gitfile()Libravatar Junio C Hamano1-3/+3
The function was not gentle at all to the callers and died without giving them a chance to deal with possible errors. Rename it to read_gitfile(), and update all the callers. As no existing caller needs a true "gently" variant, we do not bother adding one at this point. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-16rev-parse: add option --resolve-git-dir <path>Libravatar Fredrik Gustafsson1-0/+7
Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11Reduce parse-options.o dependenciesLibravatar Dmitry Ivankov1-28/+0
Currently parse-options.o pulls quite a big bunch of dependencies. his complicates it's usage in contrib/ because it pulls external dependencies and it also increases executables size. Split off less generic and more internal to git part of parse-options.c to parse-options-cb.c. Move prefix_filename function from setup.c to abspath.c. abspath.o and wrapper.o pull each other, so it's unlikely to increase the dependencies. It was a dependency of parse-options.o that pulled many others. Now parse-options.o pulls just abspath.o, ctype.o, strbuf.o, usage.o, wrapper.o, libc directly and strlcpy.o indirectly. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11Merge branch 'cb/partial-commit-relative-pathspec'Libravatar Junio C Hamano1-0/+32
* cb/partial-commit-relative-pathspec: commit: allow partial commits with relative paths
2011-08-02commit: allow partial commits with relative pathsLibravatar Clemens Buchacher1-0/+32
In order to do partial commits, git-commit overlays a tree on the cache and checks pathspecs against the result. Currently, the overlaying is done using "prefix" which prevents relative pathspecs with ".." and absolute pathspec from matching when they refer to files not under "prefix" and absent from the index, but still in the tree (i.e. files staged for removal). The point of providing a prefix at all is performance optimization. If we say there is no common prefix for the files of interest, then we have to read the entire tree into the index. But even if we cannot use the working directory as a prefix, we can still figure out if there is a common prefix for all given paths, and use that instead. The pathspec_prefix() routine from ls-files.c does exactly that. Any use of global variables is removed from pathspec_prefix() so that it can be called from commit.c. Reported-by: Reuben Thomas <rrt@sc3d.org> Analyzed-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-29Merge branch 'da/git-prefix-everywhere' into nextLibravatar Junio C Hamano1-0/+5
* da/git-prefix-everywhere: t/t7503-pre-commit-hook.sh: Add GIT_PREFIX tests git-mergetool--lib: Make vimdiff retain the current directory git: Remove handling for GIT_PREFIX setup: Provide GIT_PREFIX to built-ins
2011-05-30Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: git-submodule.sh: separate parens by a space to avoid confusing some shells Documentation/technical/api-diff.txt: correct name of diff_unmerge() read_gitfile_gently: use ssize_t to hold read result remove tests of always-false condition rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-30Merge branch 'jm/maint-misc-fix' into maintLibravatar Junio C Hamano1-1/+1
* jm/maint-misc-fix: read_gitfile_gently: use ssize_t to hold read result remove tests of always-false condition rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-26setup: Provide GIT_PREFIX to built-insLibravatar David Aguilar1-0/+5
GIT_PREFIX was added in 7cf16a14f5c070f7b14cf28023769450133172ae so that aliases can know the directory from which a !alias was called. Knowing the prefix relative to the root is helpful in other programs so export it to built-ins as well. Helped-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26read_gitfile_gently: use ssize_t to hold read resultLibravatar Jeff King1-1/+1
Otherwise, a negative error return becomes a very large read value. We catch this in practice because we compare the expected and actual numbers of bytes (and you are not likely to be reading (size_t)-1 bytes), but this makes the correctness a little more obvious. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-23Merge branch 'jc/magic-pathspec'Libravatar Junio C Hamano1-4/+111
* jc/magic-pathspec: setup.c: Fix some "symbol not declared" sparse warnings t3703: Skip tests using directory name ":" on Windows revision.c: leave a note for "a lone :" enhancement t3703, t4208: add test cases for magic pathspec rev/path disambiguation: further restrict "misspelled index entry" diag fix overslow :/no-such-string-ever-existed diagnostics fix overstrict :<path> diagnosis grep: use get_pathspec() correctly pathspec: drop "lone : means no pathspec" from get_pathspec() Revert "magic pathspec: add ":(icase)path" to match case insensitively" magic pathspec: add ":(icase)path" to match case insensitively magic pathspec: futureproof shorthand form magic pathspec: add tentative ":/path/from/top/level" pathspec support
2011-05-17setup.c: Fix some "symbol not declared" sparse warningsLibravatar Ramsay Jones1-2/+2
In particular, sparse issues the "symbol 'a_symbol' was not declared. Should it be static?" warnings for the following symbols: setup.c:159:3: 'pathspec_magic' setup.c:176:12: 'prefix_pathspec' These symbols only require file scope, so we add the static modifier to their declarations. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-10rev/path disambiguation: further restrict "misspelled index entry" diagLibravatar Junio C Hamano1-2/+11
A colon followed by anything !isalnum() (e.g. ":/heh") at this point is known not to be an existing rev. Just give a generic "neither a rev nor a path" error message. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-10fix overslow :/no-such-string-ever-existed diagnosticsLibravatar Junio C Hamano1-1/+1
"git cmd :/no-such-string-ever-existed" runs an extra round of get_sha1() since 009fee4 (Detailed diagnosis when parsing an object name fails., 2009-12-07). Once without error diagnosis to see there is no commit with such a string in the log message (hence "it cannot be a ref"), and after seeing that :/no-such-string-ever-existed is not a filename (hence "it cannot be a path, either"), another time to give "better diagnosis". The thing is, the second time it runs, we already know that traversing the history all the way down to the root will _not_ find any matching commit. Rename misguided "gently" parameter, which is turned off _only_ when the "detailed diagnosis" codepath knows that it cannot be a ref and making the call only for the caller to die with a message. Flip its meaning (and adjust the callers) and call it "only_to_die", which is not a great name, but it describes far more clearly what the codepaths that switches their behaviour based on this variable do. On my box, the command spends ~1.8 seconds without the patch to make the report; with the patch it spends ~1.12 seconds. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-10pathspec: drop "lone : means no pathspec" from get_pathspec()Libravatar Junio C Hamano1-3/+0
We may want to give the pathspec subsystem such a feature, but not while we are still using get_pathspec() that returns a stupid "char **" that loses subtle nuances that existed in the input string. In the meantime, the callers of get_pathspec() that want to support it could do an equivalent before feeding their argv[] to the function themselves quite easily. Signed-off-by: Junio C Hamano <gitster@pobox.com>