- 28 10月, 2011 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 9月, 2011 1 次提交
-
-
由 Clemens Buchacher 提交于
Also make common_prefix_len() static as this refactoring makes dir.c itself the only caller of this helper function. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 9月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 06 4月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
As the point of the last change is to allow use of strings as literals no matter what characters are in them, "has_wildcard" does not match what we use this field for anymore. It is used to decide if the wildcard matching should be used, so rename it to match the usage better. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 4月, 2011 1 次提交
-
-
由 Alex Riesen 提交于
As a last ditch effort, try rmdir(2) when we cannot read the directory to be removed. It may be an empty directory that we can remove without any permission, as long as we can modify its parent directory. Noticed by Linus. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 3月, 2011 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Function dir_inside_of() does something similar (correctly), but looks easier to understand and does not bundle cwd to its business. Given get_relative_cwd's only user is is_inside_dir, we can kill it for good. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
The same old problem reappears after setup code is reworked. We tend to assume there is at least one path component in a path and forget that path can be simply '/'. Reported-by: NMatthijs Kooijman <matthijs@stdin.nl> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 3月, 2011 1 次提交
-
-
由 Carlos Martín Nieto 提交于
Rename the make_*_path functions so it's clearer what they do, in particlar make clear what the differnce between make_absolute_path and make_nonrelative_path is by renaming them real_path and absolute_path respectively. make_relative_path has an understandable name and is renamed to relative_path to maintain the name convention. The function calls have been replaced 1-to-1 in their usage. Signed-off-by: NCarlos Martín Nieto <cmn@elego.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 2月, 2011 5 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
match_pathspec_depth() is a clone of match_pathspec() except that it can take depth limit. Computation is a bit lighter compared to match_pathspec() because it's usually precomputed and stored in struct pathspec. In long term, match_pathspec() and match_one() should be removed in favor of this function. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
never_interesting optimization is disabled if there is any wildcard pathspec, even if it only matches exactly on trees. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Suppose we have two pathspecs 'a' and 'a/b' (both are dirs) and depth limit 1. In current code, pathspecs are checked in input order. When 'a/b' is checked against pathspec 'a', it fails depth limit and therefore is excluded, although it should match 'a/b' pathspec. This patch reorders all pathspecs alphabetically, then teaches tree_entry_interesting() to check against the deepest pathspec first, so depth limit of a shallower pathspec won't affect a deeper one. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
This is needed to replace pathspec_matches() in builtin/grep.c. max_depth == -1 means infinite depth. Depth limit is only effective when pathspec.recursive == 1. When pathspec.recursive == 0, the behavior depends on match functions: non-recursive for tree_entry_interesting() and recursive for match_pathspec{,_depth} Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
The old pathspec structure remains as pathspec.raw[]. New things are stored in pathspec.items[]. There's no guarantee that the pathspec order in raw[] is exactly as in items[]. raw[] is external (source) data and is untouched by pathspec manipulation functions. It eases migration from old const char ** to this new struct. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 12月, 2010 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
This reverts commit c84de707. The commit provided a workaround for matching directories in index. But it is no longer needed. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 11月, 2010 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 11月, 2010 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Commit 490544b1 (get_cwd_relative(): do not misinterpret suffix as subdirectory) handles case where: dir = "/path/work"; cwd = "/path/work-xyz"; When it comes to the end of get_cwd_relative(), dir is at '\0' and cwd is at '-'. The rest of cwd, "-xyz", clearly cannot be the relative path from dir to cwd. However there is another case where: dir = "/"; /* or even "c:/" */ cwd = "/path/to/here"; In this special case, while *cwd == 'p', which is not a path separator, the rest of cwd, "path/to/here", can be returned as a relative path from dir to cwd. Handle this case and make t1509 pass again. Reported-by: NAlbert Strasheim <fullung@gmail.com> Reported-by: NMatthijs Kooijman <matthijs@stdin.nl> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 11月, 2010 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Commit c84de707 (excluded_1(): support exclude files in index - 2009-08-20) tries to work around the fact that there is no directory/file information in index entries, therefore EXC_FLAG_MUSTBEDIR match would fail. Unfortunately the workaround is flawed. This fixes it. Reported-by: NThomas Rinderknecht <thomasr@sailguy.org> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 10月, 2010 4 次提交
-
-
由 Joshua Jensen 提交于
When mydir/filea.txt is added, mydir/ is renamed to MyDir/, and MyDir/fileb.txt is added, running git ls-files mydir only shows mydir/filea.txt. Running git ls-files MyDir shows MyDir/fileb.txt. Running git ls-files mYdIR shows nothing. With this patch running git ls-files for mydir, MyDir, and mYdIR shows mydir/filea.txt and MyDir/fileb.txt. Wildcards are not handled case insensitively in this patch. Example: MyDir/aBc/file.txt is added. git ls-files MyDir/a* works fine, but git ls-files mydir/a* does not. Signed-off-by: NJoshua Jensen <jjensen@workspacewhiz.com> Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Joshua Jensen 提交于
When using a case preserving but case insensitive file system, directory case can differ but still refer to the same physical directory. git status reports the directory with the alternate case as an Untracked file. (That is, when mydir/filea.txt is added to the repository and then the directory on disk is renamed from mydir/ to MyDir/, git status shows MyDir/ as being untracked.) Support has been added in name-hash.c for hashing directories with a terminating slash into the name hash. When index_name_exists() is called with a directory (a name with a terminating slash), the name is not found via the normal cache_name_compare() call, but it is found in the slow_same_name() function. Additionally, in dir.c, directory_exists_in_index_icase() allows newly added directories deeper in the directory chain to be identified. Ultimately, it would be better if the file list was read in case insensitive alphabetical order from disk, but this change seems to suffice for now. The end result is the directory is looked up in a case insensitive manner and does not show in the Untracked files list. Signed-off-by: NJoshua Jensen <jjensen@workspacewhiz.com> Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Joshua Jensen 提交于
This is especially beneficial when using Windows and Perforce and the git-p4 bridge. Internally, Perforce preserves a given file's full path including its case at the time it was added to the Perforce repository. When syncing a file down via Perforce, missing directories are created, if necessary, using the case as stored with the filename. Unfortunately, two files in the same directory can have differing cases for their respective paths, such as /diRa/file1.c and /DirA/file2.c. Depending on sync order, DirA/ may get created instead of diRa/. It is possible to handle directory names in a case insensitive manner without this patch, but it is highly inconvenient, requiring each character to be specified like so: [Bb][Uu][Ii][Ll][Dd]. With this patch, the gitignore exclusions honor the core.ignorecase=true configuration setting and make the process less error prone. The above is specified like so: Build Signed-off-by: NJoshua Jensen <jjensen@workspacewhiz.com> Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Joshua Jensen 提交于
Multiple locations within this patch series alter a case sensitive string comparison call such as strcmp() to be a call to a string comparison call that selects case comparison based on the global ignore_case variable. Behaviorally, when core.ignorecase=false, the *_icase() versions are functionally equivalent to their C runtime counterparts. When core.ignorecase=true, the *_icase() versions perform a case insensitive comparison. Like Linus' earlier ignorecase patch, these may ignore filename conventions on certain file systems. By isolating filename comparisons to certain functions, support for those filename conventions may be more easily met. Signed-off-by: NJoshua Jensen <jjensen@workspacewhiz.com> Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 9月, 2010 1 次提交
-
-
由 Pat Notz 提交于
GCC 4.4.4 on MacOS incorrectly warns about potential use of uninitialized memory. Signed-off-by: NPat Notz <patnotz@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2010 1 次提交
-
-
由 Jens Lehmann 提交于
Sometimes it is useful to know if a file or directory will be ignored before it is added to the work tree. An example is "git submodule add", where it would be really nice to be able to fail with an appropriate error message before the submodule is cloned and checked out. Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 6月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
common_prefix() scans backwards from the far end of each 'next' pathspec, starting from 'len', shortening the 'prefix' using 'path' as a reference. However, there is a small opportunity for an out-of-bounds access because len is unconditionally set to prefix-1 after a "direct match" test failed. This means that if 'next' is shorter than prefix+2, we read past it. Instead of a minimal fix, simplify the loop: scan *forward* over the 'next' entry, remembering the last '/' where it matched the prefix known so far. This is far easier to read and also has the advantage that we only scan over each entry once. Acked-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 6月, 2010 1 次提交
-
-
由 Gary V. Vaughan 提交于
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git. enum style is inconsistent already, with some enums declared on one line, some over 3 lines with the enum values all on the middle line, sometimes with 1 enum value per line... and independently of that the trailing comma is sometimes present and other times absent, often mixing with/without trailing comma styles in a single file, and sometimes in consecutive enum declarations. Clearly, omitting the comma is the more portable style, and this patch changes all enum declarations to use the portable omitted dangling comma style consistently. Signed-off-by: NGary V. Vaughan <gary@thewrittenword.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 5月, 2010 1 次提交
-
-
由 Clemens Buchacher 提交于
If the current working directory is the same as the work tree path plus a suffix, e.g. 'work' and 'work-xyz', then the suffix '-xyz' would be interpreted as a subdirectory of 'work'. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 3月, 2010 1 次提交
-
-
由 Jeff King 提交于
As we walk the directory tree, if we see an ignored path, we want to add it to the ignored list only if it matches any pathspec that we were given. We used to check for the pathspec to appear explicitly. E.g., if we see "subdir/file" and it is excluded, we check to see if we have "subdir/file" in our pathspec. However, this interacts badly with the optimization to avoid recursing into ignored subdirectories. If "subdir" as a whole is ignored, then we never recurse, and consider only whether "subdir" itself is in our pathspec. It would not match a pathspec of "subdir/file" explicitly, even though it is the reason that subdir/file would be excluded. This manifests itself to the user as "git add subdir/file" failing to correctly note that the pathspec was ignored. This patch extends the in_pathspec logic to include prefix directory case. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 2月, 2010 1 次提交
-
-
由 Jeff King 提交于
If we remove a path in a/deep/subdirectory, we should try to remove as many trailing components as possible (i.e., subdirectory, then deep, then a). However, the test for the return value of rmdir was reversed, so we only ever deleted at most one level. The fix is in remove_path, so "apply" and "merge-recursive" also are fixed. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 1月, 2010 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Commit b5041c5f (Avoid writing to buffer in add_excludes_from_file_1()) tried not to append '\n' at the end because the next commit may return a buffer that does not have extra space for that. Unfortunately it left this assignment in the loop: buf[i - (i && buf[i-1] == '\r')] = 0; that can corrupt memory if "buf" is not '\n' terminated. But even if it does not corrupt memory, the last line would not be NULL-terminated, leading to errors later inside add_exclude(). This patch fixes it by reverting the faulty commit and make sure "buf" is always \n terminated. While at it, free unused memory properly. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 1月, 2010 3 次提交
-
-
由 Junio C Hamano 提交于
Given pathspecs that share a common prefix, ls-files optimized its call into recursive directory reader by starting at the common prefix directory. If you have a directory "t" with an untracked file "t/junk" in it, but the top-level .gitignore file told us to ignore "t/", this resulted in: $ git ls-files -o --exclude-standard $ git ls-files -o --exclude-standard t/ t/junk $ git ls-files -o --exclude-standard t/junk t/junk $ cd t && git ls-files -o --exclude-standard junk We could argue that you are overriding the ignore file by giving a patchspec that matches or being in that directory, but it is somewhat unexpected. Worse yet, these behave differently: $ git ls-files -o --exclude-standard t/ . $ git ls-files -o --exclude-standard t/ t/junk This patch changes the optimization so that it notices when the common prefix directory that it starts reading from is an ignored one. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The next caller I'll be adding won't have an access to struct dirent because it won't be reading from a directory stream. Split the main part of the function further into a separate function to make it usable by a caller without passing a dirent as long as it knows what type is feeding the function. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Primarily because I want to reuse it in a separate function later, but this de-dents a huge function by one tabstop which by itself is an improvement as well. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 8月, 2009 4 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
These functions are used to handle .gitignore. They are now exported so that sparse checkout can reuse. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Index does not really have "directories", attempts to match "foo/" against index will fail unless someone tries to reconstruct directories from a list of file. Observing that dtype in this function can never be NULL (otherwise it would segfault), dtype NULL will be used to say "hey.. you are matching against index" and behave properly. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
This adds index as a prerequisite for directory listing (with exclude). At the moment directory listing is used by "git clean", "git add", "git ls-files" and "git status"/"git commit" and unpack_trees()-related commands. These commands have been checked/modified to populate index before doing directory listing. add_excludes_from_file() does not enable this feature, because it is used to read .git/info/exclude and some explicit files specified by "git ls-files". Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
In the next patch, the buffer that is being used within add_excludes_from_file_1() comes from another function and does not have extra space to put \n at the end. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 7月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
When you have an embedded git work tree in your work tree (be it an orphaned submodule, or an independent checkout of an unrelated project), "git clean -d -f" blindly descended into it and removed everything. This is rarely what the user wants. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 7月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
If we have an up-to-date index entry for a file in that directory, we can know that the directories leading up to that file must be directories. No need to do an lstat() on the directory. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 7月, 2009 2 次提交
-
-
由 Linus Torvalds 提交于
On filesystems without d_type, we can look at the cache entry first. Doing an lstat() can be expensive. Reported by Dmitry Potapov for Cygwin. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Linus Torvalds 提交于
Stop the insanity with separate 'path' and 'base' arguments that must match. We don't need that crazy interface any more, since we cleaned up handling of 'path' in commit da4b3e8c. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-