Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 30 11月, 2010 1 次提交
  3. 09 11月, 2010 1 次提交
  5. 28 9月, 2010 1 次提交
  7. 13 7月, 2010 1 次提交
  9. 17 6月, 2010 1 次提交
    • J
      common_prefix: simplify and fix scanning for prefixes · 42f9852f
      由 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>
      42f9852f
  11. 01 6月, 2010 1 次提交
    • G
      enums: omit trailing comma for portability · 4b05548f
      由 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>
      4b05548f
  13. 29 5月, 2010 1 次提交
  15. 14 3月, 2010 1 次提交
    • J
      dir: fix COLLECT_IGNORED on excluded prefixes · 29209cbe
      由 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>
      29209cbe
  17. 19 2月, 2010 1 次提交
  19. 21 1月, 2010 1 次提交
    • N
      Fix memory corruption when .gitignore does not end by \n · 45d76f17
      由 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>
      45d76f17
  21. 09 1月, 2010 3 次提交
    • J
      ls-files: fix overeager pathspec optimization · 48ffef96
      由 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>
      48ffef96
    • J
      read_directory(): further split treat_path() · 16e2cfa9
      由 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>
      16e2cfa9
    • J
      read_directory_recursive(): refactor handling of a single path into a separate function · 53cc5356
      由 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>
      53cc5356
  23. 24 8月, 2009 4 次提交
  25. 30 7月, 2009 1 次提交
  27. 10 7月, 2009 1 次提交
  29. 09 7月, 2009 3 次提交
  31. 28 6月, 2009 1 次提交
  33. 01 6月, 2009 1 次提交
    • J
      git-add: no need for -f when resolving a conflict in already tracked path · 6e4f981f
      由 Jeff King 提交于 
      When a path F that matches ignore pattern has a conflict, "git add F"
insisted the -f option be given, which did not make sense.  It would have
required -f when the path was originally added, but when resolving a
conflict, it already is tracked.

So this should work (and does):

  $ echo file >.gitignore
  $ echo content >file
  $ git add -f file ;# need -f because we are adding new path
  $ echo more content >>file
  $ git add file ;# don't need -f; it is not actually an "other" file

This is handled under the hood by the COLLECT_IGNORED option to
read_directory. When that code finds an ignored file, it checks the
index to make sure it is not actually a tracked file. However, the test
it uses does not take into account unmerged entries, and considers them
to still be ignored. "git ls-files" uses a more elaborate test and gets
the right answer and the same test should be used here.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6e4f981f
  35. 17 5月, 2009 1 次提交
    • L
      dir.c: clean up handling of 'path' parameter in read_directory_recursive() · da4b3e8c
      由 Linus Torvalds 提交于 
      Right now we pass two different pathnames ('path' and 'base') down to
read_directory_recursive(), and the only real reason for that is that we
want to allow an empty 'base' parameter, but when we do so, we need the
pathname to "opendir()" to be "." rather than the empty string.

And rather than handle that confusion in the caller, we can just fix
read_directory_recursive() to handle the case of an empty path itself,
by just passing opendir() a "." ourselves if the path is empty.

This would allow us to then drop one of the pathnames entirely from the
calling convention, but rather than do that, we'll start separating them
out as a "filesystem pathname" (the one we use for filesystem accesses)
and a "git internal base name" (which is the name that we use for git
internally).

That will eventually allow us to do things like handle different
encodings (eg the filesystem pathnames might be Latin1, while git itself
would use UTF-8 for filename information).
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      da4b3e8c
  37. 06 5月, 2009 1 次提交
  39. 02 5月, 2009 1 次提交
  41. 19 2月, 2009 1 次提交
  43. 13 2月, 2009 1 次提交
    • F
      Support "\" in non-wildcard exclusion entries · dd482eea
      由 Finn Arne Gangstad 提交于 
      "\" was treated differently in exclude rules depending on whether a
wildcard match was done. For wildcard rules, "\" was de-escaped in
fnmatch, but this was not done for other rules since they used strcmp
instead.  A file named "#foo" would not be excluded by "\#foo", but would
be excluded by "\#foo*".

We now treat all rules with "\" as wildcard rules.

Another solution could be to de-escape all non-wildcard rules as we
read them, but we would have to do the de-escaping exactly as fnmatch
does it to avoid inconsistencies.
Signed-off-by: NFinn Arne Gangstad <finnag@pvv.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      dd482eea
  45. 10 2月, 2009 1 次提交
  47. 18 1月, 2009 1 次提交
    • R
      Change NUL char handling of isspecial() · 8cc32992
      由 René Scharfe 提交于 
      Replace isspecial() by the new macro is_glob_special(), which is more,
well, specialized.  The former included the NUL char in its character
class, while the letter only included characters that are special to
file name globbing.

The new name contains underscores because they enhance readability
considerably now that it's made up of three words.  Renaming the
function is necessary to document its changed scope.

The call sites of isspecial() are updated to check explicitly for NUL.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8cc32992
  49. 15 1月, 2009 2 次提交
  51. 12 1月, 2009 2 次提交
  53. 03 10月, 2008 1 次提交
  55. 29 9月, 2008 1 次提交
  57. 29 8月, 2008 1 次提交
  59. 14 8月, 2008 1 次提交
  61. 05 8月, 2008 1 次提交