This project is mirrored from https://github.com/git/git. Updated .
  1. 14 Jul, 2014 2 commits
  2. 24 Feb, 2014 4 commits
  3. 15 Aug, 2013 1 commit
    • Junio C Hamano's avatar
      ls-files -k: a directory only can be killed if the index has a non-directory · 2eac2a4c
      Junio C Hamano authored
      "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: default avatarJunio C Hamano <gitster@pobox.com>
      2eac2a4c
  4. 15 Jul, 2013 5 commits
  5. 15 Apr, 2013 3 commits
    • Karsten Blees's avatar
      dir.c: git-status --ignored: don't scan the work tree twice · 0aaf62b6
      Karsten Blees authored
      'git-status --ignored' still scans the work tree twice to collect
      untracked and ignored files, respectively.
      
      fill_directory / read_directory already supports collecting untracked and
      ignored files in a single directory scan. However, the DIR_COLLECT_IGNORED
      flag to enable this has some git-add specific side-effects (e.g. it
      doesn't recurse into ignored directories, so listing ignored files with
      --untracked=all doesn't work).
      
      The DIR_SHOW_IGNORED flag doesn't list untracked files and returns ignored
      files in dir_struct.entries[] (instead of dir_struct.ignored[] as
      DIR_COLLECT_IGNORED). DIR_SHOW_IGNORED is used all throughout git.
      
      We don't want to break the existing API, so lets introduce a new flag
      DIR_SHOW_IGNORED_TOO that lists untracked as well as ignored files similar
      to DIR_COLLECT_FILES, but will recurse into sub-directories based on the
      other flags as DIR_SHOW_IGNORED does.
      
      In dir.c::read_directory_recursive, add ignored files to either
      dir_struct.entries[] or dir_struct.ignored[] based on the flags. Also move
      the DIR_COLLECT_IGNORED case here so that filling result lists is in a
      common place.
      
      In wt-status.c::wt_status_collect_untracked, use the new flag and read
      results from dir_struct.ignored[]. Remove the extra fill_directory call.
      
      builtin/check-ignore.c doesn't call fill_directory, setting the git-add
      specific DIR_COLLECT_IGNORED flag has no effect here. Remove for clarity.
      
      Update API documentation to reflect the changes.
      
      Performance: with this patch, 'git-status --ignored' is typically as fast
      as 'git-status'.
      Signed-off-by: default avatarKarsten Blees <blees@dcon.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      0aaf62b6
    • Karsten Blees's avatar
    • Karsten Blees's avatar
      dir.c: unify is_excluded and is_path_excluded APIs · 95c6f271
      Karsten Blees authored
      The is_excluded and is_path_excluded APIs are very similar, except for a
      few noteworthy differences:
      
      is_excluded doesn't handle ignored directories, results for paths within
      ignored directories are incorrect. This is probably based on the premise
      that recursive directory scans should stop at ignored directories, which
      is no longer true (in certain cases, read_directory_recursive currently
      calls is_excluded *and* is_path_excluded to get correct ignored state).
      
      is_excluded caches parsed .gitignore files of the last directory in struct
      dir_struct. If the directory changes, it finds a common parent directory
      and is very careful to drop only as much state as necessary. On the other
      hand, is_excluded will also read and parse .gitignore files in already
      ignored directories, which are completely irrelevant.
      
      is_path_excluded correctly handles ignored directories by checking if any
      component in the path is excluded. As it uses is_excluded internally, this
      unfortunately forces is_excluded to drop and re-read all .gitignore files,
      as there is no common parent directory for the root dir.
      
      is_path_excluded tracks state in a separate struct path_exclude_check,
      which is essentially a wrapper of dir_struct with two more fields. However,
      as is_path_excluded also modifies dir_struct, it is not possible to e.g.
      use multiple path_exclude_check structures with the same dir_struct in
      parallel. The additional structure just unnecessarily complicates the API.
      
      Teach is_excluded / prep_exclude about ignored directories: whenever
      entering a new directory, first check if the entire directory is excluded.
      Remember the excluded state in dir_struct. Don't traverse into already
      ignored directories (i.e. don't read irrelevant .gitignore files).
      
      Directories could also be excluded by exclude patterns specified on the
      command line or .git/info/exclude, so we cannot simply skip prep_exclude
      entirely if there's no .gitignore file name (dir_struct.exclude_per_dir).
      Move this check to just before actually reading the file.
      
      is_path_excluded is now equivalent to is_excluded, so we can simply
      redirect to it (the public API is cleaned up in the next patch).
      
      The performance impact of the additional ignored check per directory is
      hardly noticeable when reading directories recursively (e.g. 'git status').
      However, performance of git commands using the is_path_excluded API (e.g.
      'git ls-files --cached --ignored --exclude-standard') is greatly improved
      as this no longer re-reads .gitignore files on each call.
      
      Here's some performance data from the linux and WebKit repos (best of 10
      runs on a Debian Linux on SSD, core.preloadIndex=true):
      
             | ls-files -ci   |    status      | status --ignored
             | linux | WebKit | linux | WebKit | linux | WebKit
      -------+-------+--------+-------+--------+-------+---------
      before | 0.506 |  6.539 | 0.212 |  1.555 | 0.323 |  2.541
      after  | 0.080 |  1.191 | 0.218 |  1.583 | 0.321 |  2.579
      gain   | 6.325 |  5.490 | 0.972 |  0.982 | 1.006 |  0.985
      Signed-off-by: default avatarKarsten Blees <blees@dcon.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      95c6f271
  6. 06 Jan, 2013 4 commits
    • Adam Spiers's avatar
      dir.c: improve docs for match_pathspec() and match_pathspec_depth() · 52ed1894
      Adam Spiers authored
      Fix a grammatical issue in the description of these functions, and
      make it more obvious how and why seen[] can be reused across multiple
      invocations.
      Signed-off-by: default avatarAdam Spiers <git@adamspiers.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      52ed1894
    • Adam Spiers's avatar
      dir.c: provide clear_directory() for reclaiming dir_struct memory · 270be816
      Adam Spiers authored
      By the end of a directory traversal, a dir_struct instance will
      typically contains pointers to various data structures on the heap.
      clear_directory() provides a convenient way to reclaim that memory.
      Signed-off-by: default avatarAdam Spiers <git@adamspiers.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      270be816
    • Adam Spiers's avatar
      dir.c: keep track of where patterns came from · c04318e4
      Adam Spiers authored
      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: default avatarAdam Spiers <git@adamspiers.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c04318e4
    • Adam Spiers's avatar
      dir.c: use a single struct exclude_list per source of excludes · c082df24
      Adam Spiers authored
      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: default avatarAdam Spiers <git@adamspiers.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c082df24
  7. 28 Dec, 2012 7 commits
  8. 26 Nov, 2012 2 commits
  9. 15 Oct, 2012 2 commits
  10. 07 Jun, 2012 1 commit
  11. 06 Jun, 2012 2 commits
  12. 03 Jun, 2012 1 commit
    • Junio C Hamano's avatar
      ls-files -i: pay attention to exclusion of leading paths · eb41775e
      Junio C Hamano authored
      "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: default avatarJunio C Hamano <gitster@pobox.com>
      eb41775e
  13. 15 Mar, 2012 1 commit
  14. 12 Sep, 2011 1 commit
  15. 06 Sep, 2011 1 commit
  16. 29 Mar, 2011 2 commits
  17. 03 Feb, 2011 1 commit