git/path.c, branch v2.0.2

Merge branch 'jk/config-path-include-fix'

2014-02-27T22:01:25Z

include.path variable (or any variable that expects a path that can use ~username expansion) in the configuration file is not a boolean, but the code failed to check it. * jk/config-path-include-fix: handle_path_include: don't look at NULL value expand_user_path: do not look at NULL path

expand_user_path: do not look at NULL path

2014-01-28T19:59:47Z

We explicitly check for and handle the case that the incoming "path" variable is NULL, but before doing so we call strchrnul on it, leading to a potential segfault. We can fix this simply by moving the strchrnul call down; as a bonus, we can tighten the scope on the associated variable. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jx/relative-path-regression-fix'

2013-10-28T17:42:30Z

* jx/relative-path-regression-fix: Use simpler relative_path when set_git_dir relative_path should honor dos-drive-prefix test: use unambigous leading path (/foo) for MSYS

Use simpler relative_path when set_git_dir

2013-10-14T14:00:33Z

Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc. It will make git_dir shorter only if git_dir is inside work_tree, and this will increase performance. But my last refactor effort on relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that. Always use relative_path as git_dir may bring troubles like $gmane/234434. Because new relative_path is a combination of original relative_path from path.c and original path_relative from quote.c, so in order to restore the origin implementation, save the original relative_path as remove_leading_path, and call it in setup.c. Suggested-by: Karsten Blees Signed-off-by: Jiang Xin Signed-off-by: Jonathan Nieder

relative_path should honor dos-drive-prefix

2013-10-14T14:00:26Z

Tvangeste found that the "relative_path" function could not work properly on Windows if "in" and "prefix" have DOS drive prefix (such as "C:/windows"). ($gmane/234434) E.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y", should return "C:/a/b", but returns "../../C:/a/b", which is wrong. So make relative_path honor DOS drive prefix, and add test cases for it in t0060. Reported-by: Tvangeste Helped-by: Johannes Sixt Signed-off-by: Jiang Xin Signed-off-by: Jonathan Nieder

Merge branch 'jl/submodule-mv'

2013-09-09T21:36:15Z

"git mv A B" when moving a submodule A does "the right thing", inclusing relocating its working tree and adjusting the paths in the .gitmodules file. * jl/submodule-mv: (53 commits) rm: delete .gitmodules entry of submodules removed from the work tree mv: update the path entry in .gitmodules for moved submodules submodule.c: add .gitmodules staging helper functions mv: move submodules using a gitfile mv: move submodules together with their work trees rm: do not set a variable twice without intermediate reading. t6131 - skip tests if on case-insensitive file system parse_pathspec: accept :(icase)path syntax pathspec: support :(glob) syntax pathspec: make --literal-pathspecs disable pathspec magic pathspec: support :(literal) syntax for noglob pathspec kill limit_pathspec_to_literal() as it's only used by parse_pathspec() parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN parse_pathspec: make sure the prefix part is wildcard-free rename field "raw" to "_raw" in struct pathspec tree-diff: remove the use of pathspec's raw[] in follow-rename codepath remove match_pathspec() in favor of match_pathspec_depth() remove init_pathspec() in favor of parse_pathspec() remove diff_tree_{setup,release}_paths convert common_prefix() to use struct pathspec ...

Merge branch 'rj/cygwin-clarify-use-of-cheating-lstat'

2013-08-02T18:01:01Z

Cygwin port added a "not quite correct but a lot faster and good enough for many lstat() calls that are only used to see if the working tree entity matches the index entry" lstat() emulation some time ago, and it started biting us in places. This removes it and uses the standard lstat() that comes with Cygwin. Recent topic that uses lstat on packed-refs file is broken when this cheating lstat is used, and this is a simplest fix that is also the cleanest direction to go in the long run. * rj/cygwin-clarify-use-of-cheating-lstat: cygwin: Remove the Win32 l/stat() implementation

cygwin: Remove the Win32 l/stat() implementation

2013-07-18T17:44:17Z

Commit adbc0b6b ("cygwin: Use native Win32 API for stat", 30-09-2008) added a Win32 specific implementation of the stat functions. In order to handle absolute paths, cygwin mount points and symbolic links, this implementation may fall back on the standard cygwin l/stat() functions. Also, the choice of cygwin or Win32 functions is made lazily (by the first call(s) to l/stat) based on the state of some config variables. Unfortunately, this "schizophrenic stat" implementation has been the source of many problems ever since. For example, see commits 7faee6b8, 79748439, 452993c2, 085479e7, b8a97333, 924aaf3e, 05bab3ea and 0117c2f0. In order to avoid further problems, such as the issue raised by the new reference handling API, remove the Win32 l/stat() implementation. Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

parse_pathspec: make sure the prefix part is wildcard-free

2013-07-15T17:56:09Z

Prepending prefix to pathspec is a trick to workaround the fact that commands can be executed in a subdirectory, but all git commands run at worktree's root. The prefix part should always be treated as literal string. Make it so. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

path.c: refactor relative_path(), not only strip prefix

2013-06-26T16:59:00Z

Original design of relative_path() is simple, just strip the prefix (*base) from the absolute path (*abs). In most cases, we need a real relative path, such as: ../foo, ../../bar. That's why there is another reimplementation (path_relative()) in quote.c. Borrow some codes from path_relative() in quote.c to refactor relative_path() in path.c, so that it could return real relative path, and user can reuse this function without reimplementing his/her own. The function path_relative() in quote.c will be substituted, and I would use the new relative_path() function when implementing the interactive git-clean later. Different results for relative_path() before and after this refactor: abs path base path relative (original) relative (refactor) ======== ========= =================== =================== /a/b /a/b . ./ /a/b/ /a/b . ./ /a /a/b/ /a ../ / /a/b/ / ../../ /a/c /a/b/ /a/c ../c /x/y /a/b/ /x/y ../../x/y a/b/ a/b/ . ./ a/b/ a/b . ./ a a/b a ../ x/y a/b/ x/y ../../x/y a/c a/b a/c ../c (empty) (null) (empty) ./ (empty) (empty) (empty) ./ (empty) /a/b (empty) ./ (null) (null) (null) ./ (null) (empty) (null) ./ (null) /a/b (segfault) ./ You may notice that return value "." has been changed to "./". It is because: * Function quote_path_relative() in quote.c will show the relative path as "./" if abs(in) and base(prefix) are the same. * Function relative_path() is called only once (in setup.c), and it will be OK for the return value as "./" instead of ".". Signed-off-by: Jiang Xin Signed-off-by: Junio C Hamano