1. 20 Mar, 2019 1 commit
  2. 13 Aug, 2018 1 commit
  3. 02 May, 2018 1 commit
  4. 29 Mar, 2018 1 commit
    • Stefan Beller's avatar
      submodule: fixup nested submodules after moving the submodule · da62f786
      Stefan Beller authored
      connect_work_tree_and_git_dir is used to connect a submodule worktree with
      its git directory and vice versa after events that require a reconnection
      such as moving around the working tree. As submodules can have nested
      submodules themselves, we'd also want to fix the nested submodules when
      asked to. Add an option to recurse into the nested submodules and connect
      them as well.
      
      As submodules are identified by their name (which determines their git
      directory in relation to their superproject's git directory) internally
      and by their path in the working tree of the superproject, we need to
      make sure that the mapping of name <-> path is kept intact. We can do
      that in the git-mv command by writing out the gitmodules file first
      and then forcing a reload of the submodule config machinery.
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Reviewed-by: 's avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      da62f786
  5. 07 Feb, 2018 1 commit
    • Duy Nguyen's avatar
      dir.c: ignore paths containing .git when invalidating untracked cache · 0cacebf0
      Duy Nguyen authored
      read_directory() code ignores all paths named ".git" even if it's not
      a valid git repository. See treat_path() for details. Since ".git" is
      basically invisible to read_directory(), when we are asked to
      invalidate a path that contains ".git", we can safely ignore it
      because the slow path would not consider it anyway.
      
      This helps when fsmonitor is used and we have a real ".git" repo at
      worktree top. Occasionally .git/index will be updated and if the
      fsmonitor hook does not filter it, untracked cache is asked to
      invalidate the path ".git/index".
      
      Without this patch, we invalidate the root directory unncessarily,
      which:
      
      - makes read_directory() fall back to slow path for root directory
        (slower)
      
      - makes the index dirty (because UNTR extension is updated). Depending
        on the index size, writing it down could also be slow.
      
      A note about the new "safe_path" knob. Since this new check could be
      relatively expensive, avoid it when we know it's not needed. If the
      path comes from the index, it can't contain ".git". If it does
      contain, we may be screwed up at many more levels, not just this one.
      Noticed-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      0cacebf0
  6. 30 Jan, 2018 1 commit
  7. 22 Nov, 2017 1 commit
  8. 31 Oct, 2017 1 commit
    • Jameson Miller's avatar
      status: add option to show ignored files differently · eec0f7f2
      Jameson Miller authored
      Teach the status command more flexibility in how ignored files are
      reported. Currently, the reporting of ignored files and untracked
      files are linked. You cannot control how ignored files are reported
      independently of how untracked files are reported (i.e. `all` vs
      `normal`). This makes it impossible to show untracked files with the
      `all` option, but show ignored files with the `normal` option.
      
      This work 1) adds the ability to control the reporting of ignored
      files independently of untracked files and 2) introduces the concept
      of status reporting ignored paths that explicitly match an ignored
      pattern. There are 2 benefits to these changes: 1) if a consumer needs
      all untracked files but not all ignored files, there is a performance
      benefit to not scanning all contents of an ignored directory and 2)
      returning ignored files that explicitly match a path allow a consumer
      to make more informed decisions about when a status result might be
      stale.
      
      This commit implements --ignored=matching with --untracked-files=all.
      The following commit will implement --ignored=matching with
      --untracked=files=normal.
      
      As an example of where this flexibility could be useful is that our
      application (Visual Studio) runs the status command and presents the
      output. It shows all untracked files individually (e.g. using the
      '--untracked-files==all' option), and would like to know about which
      paths are ignored. It uses information about ignored paths to make
      decisions about when the status result might have changed.
      Additionally, many projects place build output into directories inside
      a repository's working directory (e.g. in "bin/" and "obj/"
      directories). Normal usage is to explicitly ignore these 2 directory
      names in the .gitignore file (rather than or in addition to the *.obj
      pattern).If an application could know that these directories are
      explicitly ignored, it could infer that all contents are ignored as
      well and make better informed decisions about files in these
      directories. It could infer that any changes under these paths would
      not affect the output of status. Additionally, there can be a
      significant performance benefit by avoiding scanning through ignored
      directories.
      
      When status is set to report matching ignored files, it has the
      following behavior. Ignored files and directories that explicitly
      match an exclude pattern are reported. If an ignored directory matches
      an exclude pattern, then the path of the directory is returned. If a
      directory does not match an exclude pattern, but all of its contents
      are ignored, then the contained files are reported instead of the
      directory.
      Signed-off-by: 's avatarJameson Miller <jamill@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      eec0f7f2
  9. 01 Oct, 2017 1 commit
    • Ben Peart's avatar
      fsmonitor: teach git to optionally utilize a file system monitor to speed up... · 883e248b
      Ben Peart authored
      fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.
      
      When the index is read from disk, the fsmonitor index extension is used
      to flag the last known potentially dirty index entries. The registered
      core.fsmonitor command is called with the time the index was last
      updated and returns the list of files changed since that time. This list
      is used to flag any additional dirty cache entries and untracked cache
      directories.
      
      We can then use this valid state to speed up preload_index(),
      ie_match_stat(), and refresh_cache_ent() as they do not need to lstat()
      files to detect potential changes for those entries marked
      CE_FSMONITOR_VALID.
      
      In addition, if the untracked cache is turned on valid_cached_dir() can
      skip checking directories for new or changed files as fsmonitor will
      invalidate the cache only for those directories that have been
      identified as having potential changes.
      
      To keep the CE_FSMONITOR_VALID state accurate during git operations;
      when git updates a cache entry to match the current state on disk,
      it will now set the CE_FSMONITOR_VALID bit.
      
      Inversely, anytime git changes a cache entry, the CE_FSMONITOR_VALID bit
      is cleared and the corresponding untracked cache directory is marked
      invalid.
      Signed-off-by: 's avatarBen Peart <benpeart@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      883e248b
  10. 12 Jun, 2017 1 commit
  11. 22 May, 2017 2 commits
    • Samuel Lijin's avatar
      dir: expose cmp_name() and check_contains() · bbf504a9
      Samuel Lijin authored
      We want to use cmp_name() and check_contains() (which both compare
      `struct dir_entry`s, the former in terms of the sort order, the latter
      in terms of whether one lexically contains another) outside of dir.c,
      so we have to (1) change their linkage and (2) rename them as
      appropriate for the global namespace. The second is achieved by
      renaming cmp_name() to cmp_dir_entry() and check_contains() to
      check_dir_entry_contains().
      Signed-off-by: 's avatarSamuel Lijin <sxlijin@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      bbf504a9
    • Samuel Lijin's avatar
      dir: hide untracked contents of untracked dirs · fb898888
      Samuel Lijin authored
      When we taught read_directory_recursive() to recurse into untracked
      directories in search of ignored files given DIR_SHOW_IGNORED_TOO, that
      had the side effect of teaching it to collect the untracked contents of
      untracked directories. It doesn't always make sense to return these,
      though (we do need them for `clean -d`), so we introduce a flag
      (DIR_KEEP_UNTRACKED_CONTENTS) to control whether or not read_directory()
      strips dir->entries of the untracked contents of untracked dirs.
      
      We also introduce check_contains() to check if one dir_entry corresponds
      to a path which contains the path corresponding to another dir_entry.
      
      This also fixes known breakages in t7061, since status --ignored now
      searches untracked directories for ignored files.
      Signed-off-by: 's avatarSamuel Lijin <sxlijin@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      fb898888
  12. 06 May, 2017 6 commits
  13. 12 Dec, 2016 2 commits
    • Stefan Beller's avatar
      submodule: add absorb-git-dir function · f6f85861
      Stefan Beller authored
      When a submodule has its git dir inside the working dir, the submodule
      support for checkout that we plan to add in a later patch will fail.
      
      Add functionality to migrate the git directory to be absorbed
      into the superprojects git directory.
      
      The newly added code in this patch is structured such that other areas of
      Git can also make use of it. The code in the submodule--helper is a mere
      wrapper and option parser for the function
      `absorb_git_dir_into_superproject`, that takes care of embedding the
      submodules git directory into the superprojects git dir. That function
      makes use of the more abstract function for this use case
      `relocate_gitdir`, which can be used by e.g. the worktree code eventually
      to move around a git directory.
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      f6f85861
    • Stefan Beller's avatar
      move connect_work_tree_and_git_dir to dir.h · 47e83eb3
      Stefan Beller authored
      That function was primarily used by submodule code, but the function
      itself is not inherently about submodules. In the next patch we'll
      introduce relocate_git_dir, which can be used by worktrees as well,
      so find a neutral middle ground in dir.h.
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      47e83eb3
  14. 10 Oct, 2016 1 commit
    • Brandon Williams's avatar
      ls-files: add pathspec matching for submodules · 75a6315f
      Brandon Williams authored
      Pathspecs can be a bit tricky when trying to apply them to submodules.
      The main challenge is that the pathspecs will be with respect to the
      superproject and not with respect to paths in the submodule.  The
      approach this patch takes is to pass in the identical pathspec from the
      superproject to the submodule in addition to the submodule-prefix, which
      is the path from the root of the superproject to the submodule, and then
      we can compare an entry in the submodule prepended with the
      submodule-prefix to the pathspec in order to determine if there is a
      match.
      
      This patch also permits the pathspec logic to perform a prefix match against
      submodules since a pathspec could refer to a file inside of a submodule.
      Due to limitations in the wildmatch logic, a prefix match is only done
      literally.  If any wildcard character is encountered we'll simply punt
      and produce a false positive match.  More accurate matching will be done
      once inside the submodule.  This is due to the superproject not knowing
      what files could exist in the submodule.
      Signed-off-by: 's avatarBrandon Williams <bmwill@google.com>
      Reviewed-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      75a6315f
  15. 05 May, 2016 1 commit
  16. 22 Apr, 2016 2 commits
  17. 18 Mar, 2016 1 commit
  18. 01 Mar, 2016 1 commit
  19. 15 Feb, 2016 1 commit
  20. 25 Jan, 2016 3 commits
  21. 24 Mar, 2015 1 commit
    • Junio C Hamano's avatar
      report_path_error(): move to dir.c · 777c55a6
      Junio C Hamano authored
      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: 's avatarJunio C Hamano <gitster@pobox.com>
      777c55a6
  22. 12 Mar, 2015 9 commits
    • Duy Nguyen's avatar
      untracked cache: guard and disable on system changes · 1e8fef60
      Duy Nguyen authored
      If the user enables untracked cache, then
      
       - move worktree to an unsupported filesystem
       - or simply upgrade OS
       - or move the whole (portable) disk from one machine to another
       - or access a shared fs from another machine
      
      there's no guarantee that untracked cache can still function properly.
      Record the worktree location and OS footprint in the cache. If it
      changes, err on the safe side and disable the cache. The user can
      'update-index --untracked-cache' again to make sure all conditions are
      met.
      
      This adds a new requirement that setup_git_directory* must be called
      before read_cache() because we need worktree location by then, or the
      cache is dropped.
      
      This change does not cover all bases, you can fool it if you try
      hard. The point is to stop accidents.
      Helped-by: Eric Sunshine's avatarEric Sunshine <sunshine@sunshineco.com>
      Helped-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Helped-by: 's avatarTorsten Bögershausen <tboegi@web.de>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      1e8fef60
    • Duy Nguyen's avatar
    • Duy Nguyen's avatar
      untracked cache: invalidate at index addition or removal · e931371a
      Duy Nguyen authored
      Ideally we should implement untracked_cache_remove_from_index() and
      untracked_cache_add_to_index() so that they update untracked cache
      right away instead of invalidating it and wait for read_directory()
      next time to deal with it. But that may need some more work in
      unpack-trees.c. So stay simple as the first step.
      
      The new call in add_index_entry_with_check() may look strange because
      new calls usually stay close to cache_tree_invalidate_path(). We do it
      a bit later than c_t_i_p() in this function because if it's about
      replacing the entry with the same name, we don't care (but cache-tree
      does).
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      e931371a
    • Duy Nguyen's avatar
    • Duy Nguyen's avatar
      untracked cache: mark what dirs should be recursed/saved · 26cb0182
      Duy Nguyen authored
      If we redo this thing in a functional style, we would have one struct
      untracked_dir as input tree and another as output. The input is used
      for verification. The output is a brand new tree, reflecting current
      worktree.
      
      But that means recreate a lot of dir nodes even if a lot could be
      shared between input and output trees in good cases. So we go with the
      messy but efficient way, combining both input and output trees into
      one. We need a way to know which node in this combined tree belongs to
      the output. This is the purpose of this "recurse" flag.
      
      "valid" bit can't be used for this because it's about data of the node
      except the subdirs. When we invalidate a directory, we want to keep
      cached data of the subdirs intact even though we don't really know
      what subdir still exists (yet). Then we check worktree to see what
      actual subdir remains on disk. Those will have 'recurse' bit set
      again. If cached data for those are still valid, we may be able to
      avoid computing exclude files for them. Those subdirs that are deleted
      will have 'recurse' remained clear and their 'valid' bits do not
      matter.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      26cb0182
    • Duy Nguyen's avatar
      untracked cache: record/validate dir mtime and reuse cached output · 91a2288b
      Duy Nguyen authored
      The main readdir loop in read_directory_recursive() is replaced with a
      new one that checks if cached results of a directory is still valid.
      
      If a file is added or removed from the index, the containing directory
      is invalidated (but not its subdirs). If directory's mtime is changed,
      the same happens. If a .gitignore is updated, the containing directory
      and all subdirs are invalidated recursively. If dir_struct#flags or
      other conditions change, the cache is ignored.
      
      If a directory is invalidated, we opendir/readdir/closedir and run the
      exclude machinery on that directory listing as usual. If untracked
      cache is also enabled, we'll update the cache along the way. If a
      directory is validated, we simply pull the untracked listing out from
      the cache. The cache also records the list of direct subdirs that we
      have to recurse in. Fully excluded directories are seen as "untracked
      files".
      
      In the best case when no dirs are invalidated, read_directory()
      becomes a series of
      
        stat(dir), open(.gitignore), fstat(), read(), close() and optionally
        hash_sha1_file()
      
      For comparison, standard read_directory() is a sequence of
      
        opendir(), readdir(), open(.gitignore), fstat(), read(), close(), the
        expensive last_exclude_matching() and closedir().
      
      We already try not to open(.gitignore) if we know it does not exist,
      so open/fstat/read/close sequence does not apply to every
      directory. The sequence could be reduced further, as noted in
      prep_exclude() in another patch. So in theory, the entire best-case
      read_directory sequence could be reduced to a series of stat() and
      nothing else.
      
      This is not a silver bullet approach. When you compile a C file, for
      example, the old .o file is removed and a new one with the same name
      created, effectively invalidating the containing directory's cache
      (but not its subdirectories). If your build process touches every
      directory, this cache adds extra overhead for nothing, so it's a good
      idea to separate generated files from tracked files.. Editors may use
      the same strategy for saving files. And of course you're out of luck
      running your repo on an unsupported filesystem and/or operating system.
      Helped-by: Eric Sunshine's avatarEric Sunshine <sunshine@sunshineco.com>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      91a2288b
    • Duy Nguyen's avatar
      untracked cache: initial untracked cache validation · ccad261f
      Duy Nguyen authored
      Make sure the starting conditions and all global exclude files are
      good to go. If not, either disable untracked cache completely, or wipe
      out the cache and start fresh.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      ccad261f
    • Duy Nguyen's avatar
      untracked cache: record .gitignore information and dir hierarchy · 0dcb8d7f
      Duy Nguyen authored
      The idea is if we can capture all input and (non-rescursive) output of
      read_directory_recursive(), and can verify later that all the input is
      the same, then the second r_d_r() should produce the same output as in
      the first run.
      
      The requirement for this to work is stat info of a directory MUST
      change if an entry is added to or removed from that directory (and
      should not change often otherwise). If your OS and filesystem do not
      meet this requirement, untracked cache is not for you. Most file
      systems on *nix should be fine. On Windows, NTFS is fine while FAT may
      not be [1] even though FAT on Linux seems to be fine.
      
      The list of input of r_d_r() is in the big comment block in dir.h. In
      short, the output of a directory (not counting subdirs) mainly depends
      on stat info of the directory in question, all .gitignore leading to
      it and the check_only flag when r_d_r() is called recursively. This
      patch records all this info (and the output) as r_d_r() runs.
      
      Two hash_sha1_file() are required for $GIT_DIR/info/exclude and
      core.excludesfile unless their stat data matches. hash_sha1_file() is
      only needed when .gitignore files in the worktree are modified,
      otherwise their SHA-1 in index is used (see the previous patch).
      
      We could store stat data for .gitignore files so we don't have to
      rehash them if their content is different from index, but I think
      .gitignore files are rarely modified, so not worth extra cache data
      (and hashing penalty read-cache.c:verify_hdr(), as we will be storing
      this as an index extension).
      
      The implication is, if you change .gitignore, you better add it to the
      index soon or you lose all the benefit of untracked cache because a
      modified .gitignore invalidates all subdirs recursively. This is
      especially bad for .gitignore at root.
      
      This cached output is about untracked files only, not ignored files
      because the number of tracked files is usually small, so small cache
      overhead, while the number of ignored files could go really high
      (e.g. *.o files mixing with source code).
      
      [1] "Description of NTFS date and time stamps for files and folders"
          http://support.microsoft.com/kb/299648Helped-by: 's avatarTorsten Bögershausen <tboegi@web.de>
      Helped-by: 's avatarDavid Turner <dturner@twopensource.com>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      0dcb8d7f
    • Duy Nguyen's avatar
      dir.c: optionally compute sha-1 of a .gitignore file · 55fe6f51
      Duy Nguyen authored
      This is not used anywhere yet. But the goal is to compare quickly if a
      .gitignore file has changed when we have the SHA-1 of both old (cached
      somewhere) and new (from index or a tree) versions.
      Helped-by: 's avatarJunio C Hamano <gitster@pobox.com>
      Helped-by: 's avatarTorsten Bögershausen <tboegi@web.de>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      55fe6f51