Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 8月, 2015 1 次提交
  3. 25 3月, 2015 1 次提交
    • J
      report_path_error(): move to dir.c · 777c55a6
      由 Junio C Hamano 提交于 
      The expected call sequence is for the caller to use match_pathspec()
repeatedly on a set of pathspecs, accumulating the "hits" in a
separate array, and then call this function to diagnose a pathspec
that never matched anything, as that can indicate a typo from the
command line, e.g. "git commit Maekfile".

Many builtin commands use this function from builtin/ls-files.c,
which is not a very healthy arrangement.  ls-files might have been
the first command to feel the need for such a helper, but the need
is shared by everybody who uses the "match and then report" pattern.

Move it to dir.c where match_pathspec() is defined.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      777c55a6
  5. 15 1月, 2015 1 次提交
  7. 03 9月, 2014 1 次提交
  9. 25 2月, 2014 3 次提交
  11. 16 8月, 2013 1 次提交
    • J
      ls-files -k: a directory only can be killed if the index has a non-directory · 2eac2a4c
      由 Junio C Hamano 提交于 
      "ls-files -o" and "ls-files -k" both traverse the working tree down
to find either all untracked paths or those that will be "killed"
(removed from the working tree to make room) when the paths recorded
in the index are checked out.  It is necessary to traverse the
working tree fully when enumerating all the "other" paths, but when
we are only interested in "killed" paths, we can take advantage of
the fact that paths that do not overlap with entries in the index
can never be killed.

The treat_one_path() helper function, which is called during the
recursive traversal, is the ideal place to implement an
optimization.

When we are looking at a directory P in the working tree, there are
three cases:

 (1) P exists in the index.  Everything inside the directory P in
     the working tree needs to go when P is checked out from the
     index.

 (2) P does not exist in the index, but there is P/Q in the index.
     We know P will stay a directory when we check out the contents
     of the index, but we do not know yet if there is a directory
     P/Q in the working tree to be killed, so we need to recurse.

 (3) P does not exist in the index, and there is no P/Q in the index
     to require P to be a directory, either.  Only in this case, we
     know that everything inside P will not be killed without
     recursing.

Note that this helper is called by treat_leading_path() that decides
if we need to traverse only subdirectories of a single common
leading directory, which is essential for this optimization to be
correct.  This caller checks each level of the leading path
component from shallower directory to deeper ones, and that is what
allows us to only check if the path appears in the index.  If the
call to treat_one_path() weren't there, given a path P/Q/R, the real
traversal may start from directory P/Q/R, even when the index
records P as a regular file, and we would end up having to check if
any leading subpath in P/Q/R, e.g. P, appears in the index.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2eac2a4c
  13. 06 8月, 2013 1 次提交
  15. 16 7月, 2013 6 次提交
  17. 10 7月, 2013 1 次提交
    • N
      Convert "struct cache_entry *" to "const ..." wherever possible · 9c5e6c80
      由 Nguyễn Thái Ngọc Duy 提交于 
      I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is

 - diff-lib.c: setting CE_UPTODATE

 - name-hash.c: setting CE_HASHED

 - preload-index.c, read-cache.c, unpack-trees.c and
   builtin/update-index: obvious

 - entry.c: write_entry() may refresh the checked out entry via
   fill_stat_cache_info(). This causes "non-const struct cache_entry
   *" in builtin/apply.c, builtin/checkout-index.c and
   builtin/checkout.c

 - builtin/ls-files.c: --with-tree changes stagemask and may set
   CE_UPDATE

Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.

So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.

The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:

    diff --git a/cache.h b/cache.h
    index 430d021..1692891 100644
    --- a/cache.h
    +++ b/cache.h
    @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
     #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)

     struct index_state {
    -	struct cache_entry **cache;
    +	const struct cache_entry **cache;
     	unsigned int version;
     	unsigned int cache_nr, cache_alloc, cache_changed;
     	struct string_list *resolve_undo;

will help quickly identify them without bogus warnings.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9c5e6c80
  19. 27 6月, 2013 3 次提交
    • J
      write_name{_quoted_relative,}(): remove redundant parameters · e9a820ce
      由 Jiang Xin 提交于 
      After substitute path_relative() in quote.c with relative_path()
from path.c, parameters (such as len and prefix_len) are redundant
in function write_name() and write_name_quoted_relative().  The
callers have already been audited that the strings they pass are
properly NUL terminated and the length they give are the length of
the string (or -1 that asks the length to be counted by the callee).

Remove these now-redundant parameters.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e9a820ce
    • J
      quote_path_relative(): remove redundant parameter · 39598f99
      由 Jiang Xin 提交于 
      quote_path_relative() used to take a counted string as its parameter
(the string to be quoted).  With an earlier change, it now uses
relative_path() that does not take a counted string, and we have
been passing only the pointer to the string since then.

Remove the length parameter from quote_path_relative() to show that
this parameter was redundant.  All the changed lines show that the
caller passed either -1 (to ask the function run strlen() on the
string), or the length of the string, so the earlier conversion was
safe.

All the callers of quote_path_relative() that used to take counted string
have been audited to make sure that they are passing length of the actual
string (or -1 to ask the callee run strlen())
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      39598f99
    • J
      quote.c: substitute path_relative with relative_path · ad66df2d
      由 Jiang Xin 提交于 
      Substitute the function path_relative in quote.c with the function
relative_path. Function relative_path can be treated as an enhanced
and more robust version of path_relative.

Outputs of path_relative and it's replacement (relative_path) are the
same for the following cases:

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/c/   /a/b/      c/                       c/
    /a/b/c    /a/b/      c                        c
    /a/       /a/b/      ../                      ../
    /         /a/b/      ../../                   ../../
    /a/c      /a/b/      ../c                     ../c
    /x/y      /a/b/      ../../x/y                ../../x/y
    a/b/c/    a/b/       c/                       c/
    a/        a/b/       ../                      ../
    x/y       a/b/       ../../x/y                ../../x/y
    /a/b      (empty)    /a/b                     /a/b
    /a/b      (null)     /a/b                     /a/b
    a/b       (empty)    a/b                      a/b
    a/b       (null)     a/b                      a/b

But if both of the path and the prefix are the same, or the returned
relative path should be the current directory, the outputs of both
functions are different. Function relative_path returns "./", while
function path_relative returns empty string.

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/     /a/b/      (empty)                  ./
    a/b/      a/b/       (empty)                  ./
    (empty)   (null)     (empty)                  ./
    (empty)   (empty)    (empty)                  ./

But the callers of path_relative can handle such cases, or never
encounter this issue at all, because:

 * In function quote_path_relative, if the output of path_relative is
   empty, append "./" to it, like:

       if (!out->len)
           strbuf_addstr(out, "./");

 * Another caller is write_name_quoted_relative, which is only used
   by builtin/ls-files.c. git-ls-files only show files, so path of
   files will never be identical with the prefix of a directory.

The following differences show that path_relative does not handle
extra slashes properly:

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a//b//c/ //a/b//    ../../../../a//b//c/     c/
    a/b//c    a//b       ../b//c                  c

And if prefix has no trailing slash, path_relative does not work
properly either.  But since prefix always has a trailing slash, it's
not a problem.

    path      prefix     output of path_relative  output of relative_path
    ========  =========  =======================  =======================
    /a/b/c/   /a/b       b/c/                     c/
    /a/b      /a/b       b                        ./
    /a/b/     /a/b       b/                       ./
    /a        /a/b/      ../../a                  ../
    a/b/c/    a/b        b/c/                     c/
    a/b/      a/b        b/                       ./
    a         a/b        ../a                     ../
    x/y       a/b/       ../x/y                   ../../x/y
    a/c       a/b        c                        ../c
    /a/       /a/b       (empty)                  ../
    (empty)   /a/b       ../../                   ./

One tricky part in this conversion is write_name() function in
ls-files.c.  It takes a counted string, <name, len>, that is to be
made relative to <prefix, prefix_len> and then quoted.  Because
write_name_quoted_relative() still takes these two parameters as
counted string, but ignores the count and treat these two as
NUL-terminated strings, this conversion needs to be audited for its
callers:

 - For <name, len>, all three callers of write_name() passes a
   NUL-terminated string and its true length, so this patch makes
   "len" unused.

 - For <prefix, prefix_len>, prefix could be a string that is longer
   than empty while prefix_len could be 0 when "--full-name" option
   is used.  This is fixed by checking prefix_len in write_name()
   and calling write_name_quoted_relative() with NULL when
   prefix_len is set to 0.  Again, this makes "prefix_len" given to
   write_name_quoted_relative() unused, without introducing a bug.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ad66df2d
  21. 21 6月, 2013 1 次提交
  23. 14 6月, 2013 1 次提交
  25. 16 4月, 2013 1 次提交
  27. 17 1月, 2013 1 次提交
  29. 07 1月, 2013 2 次提交
    • A
      dir.c: keep track of where patterns came from · c04318e4
      由 Adam Spiers 提交于 
      For exclude patterns read in from files, the filename is stored in the
exclude list, and the originating line number is stored in the
individual exclude (counting starting at 1).

For exclude patterns provided on the command line, a string describing
the source of the patterns is stored in the exclude list, and the
sequence number assigned to each exclude pattern is negative, with
counting starting at -1.  So for example the 2nd pattern provided via
--exclude would be numbered -2.  This allows any future consumers of
that data to easily distinguish between exclude patterns from files
vs. from the CLI.
Signed-off-by: NAdam Spiers <git@adamspiers.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c04318e4
    • A
      dir.c: use a single struct exclude_list per source of excludes · c082df24
      由 Adam Spiers 提交于 
      Previously each exclude_list could potentially contain patterns
from multiple sources.  For example dir->exclude_list[EXC_FILE]
would typically contain patterns from .git/info/exclude and
core.excludesfile, and dir->exclude_list[EXC_DIRS] could contain
patterns from multiple per-directory .gitignore files during
directory traversal (i.e. when dir->exclude_stack was more than
one item deep).

We split these composite exclude_lists up into three groups of
exclude_lists (EXC_CMDL / EXC_DIRS / EXC_FILE as before), so that each
exclude_list now contains patterns from a single source.  This will
allow us to cleanly track the origin of each pattern simply by adding
a src field to struct exclude_list, rather than to struct exclude,
which would make memory management of the source string tricky in the
EXC_DIRS case where its contents are dynamically generated.

Similarly, by moving the filebuf member from struct exclude_stack to
struct exclude_list, it allows us to track and subsequently free
memory buffers allocated during the parsing of all exclude files,
rather than only tracking buffers allocated for files in the EXC_DIRS
group.
Signed-off-by: NAdam Spiers <git@adamspiers.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c082df24
  31. 29 12月, 2012 1 次提交
  33. 20 11月, 2012 1 次提交
  35. 21 8月, 2012 1 次提交
  37. 06 6月, 2012 1 次提交
  39. 04 6月, 2012 1 次提交
    • J
      ls-files -i: pay attention to exclusion of leading paths · eb41775e
      由 Junio C Hamano 提交于 
      "git ls-files --exclude=t/ -i" does not show paths in directory t/
that have been added to the index, but it should.

The excluded() API was designed for callers who walk the tree from
the top, checking each level of the directory hierarchy as it
descends if it is excluded, and not even bothering to recurse into
an excluded directory.  This would allow us optimize for a common
case by not having to check if the exclude pattern "foo/" matches
when looking at "foo/bar", because the caller should have noticed
that "foo" is excluded and did not even bother to read "foo/bar"
out of opendir()/readdir() to call it.

The code for "ls-files -i" however walks the index linearly, feeding
paths without checking if the leading directory is already excluded.

Introduce a helper function path_excluded() to let this caller
properly call excluded() check for higher hierarchies as necessary.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      eb41775e
  41. 13 9月, 2011 1 次提交
  43. 07 9月, 2011 1 次提交
  45. 12 8月, 2011 1 次提交
    • C
      ls-files: fix pathspec display on error · 0f64bfa9
      由 Clemens Buchacher 提交于 
      The following sequence of commands reveals an issue with error
reporting of relative paths:

 $ mkdir sub
 $ cd sub
 $ git ls-files --error-unmatch ../bbbbb
 error: pathspec 'b' did not match any file(s) known to git.
 $ git commit --error-unmatch ../bbbbb
 error: pathspec 'b' did not match any file(s) known to git.

This bug is visible only if the normalized path (i.e., the relative
path from the repository root) is longer than the prefix.
Otherwise, the code skips over the normalized path and reads from
an unused memory location which still contains a leftover of the
original command line argument.

So instead, use the existing facilities to deal with relative paths
correctly.

Also fix inconsistency between "checkout" and "commit", e.g.

    $ cd Documentation
    $ git checkout nosuch.txt
    error: pathspec 'Documentation/nosuch.txt' did not match...
    $ git commit nosuch.txt
    error: pathspec 'nosuch.txt' did not match...

by propagating the prefix down the codepath that reports the error.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0f64bfa9
  47. 03 8月, 2011 1 次提交
    • C
      commit: allow partial commits with relative paths · 8894d535
      由 Clemens Buchacher 提交于 
      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: NReuben Thomas <rrt@sc3d.org>
Analyzed-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8894d535
  49. 06 4月, 2011 1 次提交
  51. 26 3月, 2011 1 次提交
  53. 23 10月, 2010 1 次提交
  55. 09 10月, 2010 1 次提交
  57. 03 8月, 2010 1 次提交
  59. 06 7月, 2010 1 次提交