git/dir.c, branch v2.6.2

Merge branch 'js/icase-wt-detection' into maint

2015-10-16T21:32:46Z

On a case insensitive filesystems, setting GIT_WORK_TREE variable using a random cases that does not agree with what the filesystem thinks confused Git that it wasn't inside the working tree. * js/icase-wt-detection: setup: fix "inside work tree" detection on case-insensitive filesystems

setup: fix "inside work tree" detection on case-insensitive filesystems

2015-09-28T17:49:06Z

Git has a config variable to indicate that it is operating on a file system that is case-insensitive: core.ignoreCase. But the `dir_inside_of()` function did not respect that. As a result, if Git's idea of the current working directory disagreed in its upper/lower case with the `GIT_WORK_TREE` variable (e.g. `C:\test` vs `c:\test`) the user would be greeted by the error message fatal: git-am cannot be used without a working tree. when trying to run a rebase. This fixes https://github.com/git-for-windows/git/issues/402 (reported by Daniel Harding). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'dt/untracked-subdir' into maint

2015-09-17T19:12:29Z

The experimental untracked-cache feature were buggy when paths with a few levels of subdirectories are involved. * dt/untracked-subdir: untracked cache: fix entry invalidation untracked-cache: fix subdirectory handling t7063: use --force-untracked-cache to speed up a bit untracked-cache: support sparse checkout

Merge branch 'dt/untracked-subdir'

2015-08-28T19:32:15Z

Merge branch 'jk/git-path'

2015-08-19T21:48:56Z

git_path() and mkpath() are handy helper functions but it is easy to misuse, as the callers need to be careful to keep the number of active results below 4. Their uses have been reduced. * jk/git-path: memoize common git-path "constant" files get_repo_path: refactor path-allocation find_hook: keep our own static buffer refs.c: remove_empty_directories can take a strbuf refs.c: avoid git_path assignment in lock_ref_sha1_basic refs.c: avoid repeated git_path calls in rename_tmp_log refs.c: simplify strbufs in reflog setup and writing path.c: drop git_path_submodule refs.c: remove extra git_path calls from read_loose_refs remote.c: drop extraneous local variable from migrate_file prefer mkpathdup to mkpath in assignments prefer git_pathdup to git_path in some possibly-dangerous cases add_to_alternates_file: don't add duplicate entries t5700: modernize style cache.h: complete set of git_path_submodule helpers cache.h: clarify documentation for git_path, et al

Merge branch 'cb/uname-in-untracked' into maint

2015-08-19T21:41:28Z

An experimental "untracked cache" feature used uname(2) in a slightly unportable way. * cb/uname-in-untracked: untracked: fix detection of uname(2) failure

untracked cache: fix entry invalidation

2015-08-19T17:40:55Z

First, the current code in untracked_cache_invalidate_path() is wrong because it can only handle paths "a" or "a/b", not "a/b/c" because lookup_untracked() only looks for entries directly under the given directory. In the last case, it will look for the entry "b/c" in directory "a" instead. This means if you delete or add an entry in a subdirectory, untracked cache may become out of date because it does not invalidate properly. This is noticed by David Turner. The second problem is about invalidation inside a fully untracked/excluded directory. In this case we may have to invalidate back to root. See the comment block for detail. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

untracked-cache: fix subdirectory handling

2015-08-19T17:40:24Z

Previously, some calls lookup_untracked would pass a full path. But lookup_untracked assumes that the portion of the path up to and including to the untracked_cache_dir has been removed. So lookup_untracked would be looking in the untracked_cache for 'foo' for 'foo/bar' (instead of just looking for 'bar'). This would cause untracked cache corruption. Instead, treat_directory learns to track the base length of the parent directory, so that only the last path component is passed to lookup_untracked. Helped-by: Nguyễn Thái Ngọc Duy Signed-off-by: David Turner Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'dt/untracked-sparse'

2015-08-17T22:07:52Z

Allow untracked cache (experimental) to be used when sparse checkout (experimental) is also in use. * dt/untracked-sparse: untracked-cache: support sparse checkout

memoize common git-path "constant" files

2015-08-10T22:37:14Z

One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano