1. 15 Mar, 2012 1 commit
  2. 12 Sep, 2011 1 commit
  3. 06 Sep, 2011 1 commit
  4. 29 Mar, 2011 2 commits
  5. 03 Feb, 2011 2 commits
  6. 29 Nov, 2010 1 commit
  7. 06 Oct, 2010 1 commit
    • Joshua Jensen's avatar
      Add string comparison functions that respect the ignore_case variable. · 8cf2a84e
      Joshua Jensen authored
      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: default avatarJoshua Jensen <[email protected]>
      Signed-off-by: default avatarJohannes Sixt <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      8cf2a84e
  8. 12 Jul, 2010 1 commit
  9. 24 Aug, 2009 1 commit
  10. 29 Jul, 2009 1 commit
  11. 09 Jul, 2009 2 commits
    • Linus Torvalds's avatar
      Simplify read_directory[_recursive]() arguments · dba2e203
      Linus Torvalds authored
      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: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      dba2e203
    • Linus Torvalds's avatar
      Add 'fill_directory()' helper function for directory traversal · 1d8842d9
      Linus Torvalds authored
      Most of the users of "read_directory()" actually want a much simpler
      interface than the whole complex (but rather powerful) one.
      
      In fact 'git add' had already largely abstracted out the core interface
      issues into a private "fill_directory()" function that was largely
      applicable almost as-is to a number of callers.  Yes, 'git add' wants to
      do some extra work of its own, specific to the add semantics, but we can
      easily split that out, and use the core as a generic function.
      
      This function does exactly that, and now that much simplified
      'fill_directory()' function can be shared with a number of callers,
      while also ensuring that the rather more complex calling conventions of
      read_directory() are used by fewer call-sites.
      
      This also makes the 'common_prefix()' helper function private to dir.c,
      since all callers are now in that file.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1d8842d9
  12. 18 Feb, 2009 1 commit
  13. 11 Jan, 2009 2 commits
  14. 03 Oct, 2008 1 commit
  15. 29 Sep, 2008 1 commit
  16. 05 Feb, 2008 2 commits
    • Junio C Hamano's avatar
      gitignore: lazily find dtype · 6831a88a
      Junio C Hamano authored
      When we process "foo/" entries in gitignore files on a system
      that does not have d_type member in "struct dirent", the earlier
      implementation ran lstat(2) separately when matching with
      entries that came from the command line, in-tree .gitignore
      files, and $GIT_DIR/info/excludes file.
      
      This optimizes it by delaying the lstat(2) call until it becomes
      absolutely necessary.
      
      The initial idea for this change was by Jeff King, but I
      optimized it further to pass pointers to around.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      6831a88a
    • Junio C Hamano's avatar
      gitignore(5): Allow "foo/" in ignore list to match directory "foo" · d6b8fc30
      Junio C Hamano authored
      A pattern "foo/" in the exclude list did not match directory
      "foo", but a pattern "foo" did.  This attempts to extend the
      exclude mechanism so that it would while not matching a regular
      file or a symbolic link "foo".  In order to differentiate a
      directory and non directory, this passes down the type of path
      being checked to excluded() function.
      
      A downside is that the recursive directory walk may need to run
      lstat(2) more often on systems whose "struct dirent" do not give
      the type of the entry; earlier it did not have to do so for an
      excluded path, but we now need to figure out if a path is a
      directory before deciding to exclude it.  This is especially bad
      because an idea similar to the earlier CE_UPTODATE optimization
      to reduce number of lstat(2) calls would by definition not apply
      to the codepaths involved, as (1) directories will not be
      registered in the index, and (2) excluded paths will not be in
      the index anyway.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      d6b8fc30
  17. 29 Nov, 2007 1 commit
    • Junio C Hamano's avatar
      per-directory-exclude: lazily read .gitignore files · 63d285c8
      Junio C Hamano authored
      Operations that walk directories or trees, which potentially need to
      consult the .gitignore files, used to always try to open the .gitignore
      file every time they entered a new directory, even when they ended up
      not needing to call excluded() function to see if a path in the
      directory is ignored.  This was done by push/pop exclude_per_directory()
      functions that managed the data in a stack.
      
      This changes the directory walking API to remove the need to call these
      two functions.  Instead, the directory walk data structure caches the
      data used by excluded() function the last time, and lazily reuses it as
      much as possible.  Among the data the last check used, the ones from
      deeper directories that the path we are checking is outside are
      discarded, data from the common leading directories are reused, and then
      the directories between the common directory and the directory the path
      being checked is in are checked for .gitignore file.  This is very
      similar to the way gitattributes are handled.
      
      This API change also fixes "ls-files -c -i", which called excluded()
      without setting up the gitignore data via the old push/pop functions.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      63d285c8
  18. 17 Nov, 2007 1 commit
    • Junio C Hamano's avatar
      core.excludesfile clean-up · dcf0c16e
      Junio C Hamano authored
      There are inconsistencies in the way commands currently handle
      the core.excludesfile configuration variable.  The problem is
      the variable is too new to be noticed by anything other than
      git-add and git-status.
      
       * git-ls-files does not notice any of the "ignore" files by
         default, as it predates the standardized set of ignore files.
         The calling scripts established the convention to use
         .git/info/exclude, .gitignore, and later core.excludesfile.
      
       * git-add and git-status know about it because they call
         add_excludes_from_file() directly with their own notion of
         which standard set of ignore files to use.  This is just a
         stupid duplication of code that need to be updated every time
         the definition of the standard set of ignore files is
         changed.
      
       * git-read-tree takes --exclude-per-directory=<gitignore>,
         not because the flexibility was needed.  Again, this was
         because the option predates the standardization of the ignore
         files.
      
       * git-merge-recursive uses hardcoded per-directory .gitignore
         and nothing else.  git-clean (scripted version) does not
         honor core.* because its call to underlying ls-files does not
         know about it.  git-clean in C (parked in 'pu') doesn't either.
      
      We probably could change git-ls-files to use the standard set
      when no excludes are specified on the command line and ignore
      processing was asked, or something like that, but that will be a
      change in semantics and might break people's scripts in a subtle
      way.  I am somewhat reluctant to make such a change.
      
      On the other hand, I think it makes perfect sense to fix
      git-read-tree, git-merge-recursive and git-clean to follow the
      same rule as other commands.  I do not think of a valid use case
      to give an exclude-per-directory that is nonstandard to
      read-tree command, outside a "negative" test in the t1004 test
      script.
      
      This patch is the first step to untangle this mess.
      
      The next step would be to teach read-tree, merge-recursive and
      clean (in C) to use setup_standard_excludes().
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      dcf0c16e
  19. 14 Nov, 2007 1 commit
    • Junio C Hamano's avatar
      core.excludesfile clean-up · 039bc64e
      Junio C Hamano authored
      There are inconsistencies in the way commands currently handle
      the core.excludesfile configuration variable.  The problem is
      the variable is too new to be noticed by anything other than
      git-add and git-status.
      
       * git-ls-files does not notice any of the "ignore" files by
         default, as it predates the standardized set of ignore files.
         The calling scripts established the convention to use
         .git/info/exclude, .gitignore, and later core.excludesfile.
      
       * git-add and git-status know about it because they call
         add_excludes_from_file() directly with their own notion of
         which standard set of ignore files to use.  This is just a
         stupid duplication of code that need to be updated every time
         the definition of the standard set of ignore files is
         changed.
      
       * git-read-tree takes --exclude-per-directory=<gitignore>,
         not because the flexibility was needed.  Again, this was
         because the option predates the standardization of the ignore
         files.
      
       * git-merge-recursive uses hardcoded per-directory .gitignore
         and nothing else.  git-clean (scripted version) does not
         honor core.* because its call to underlying ls-files does not
         know about it.  git-clean in C (parked in 'pu') doesn't either.
      
      We probably could change git-ls-files to use the standard set
      when no excludes are specified on the command line and ignore
      processing was asked, or something like that, but that will be a
      change in semantics and might break people's scripts in a subtle
      way.  I am somewhat reluctant to make such a change.
      
      On the other hand, I think it makes perfect sense to fix
      git-read-tree, git-merge-recursive and git-clean to follow the
      same rule as other commands.  I do not think of a valid use case
      to give an exclude-per-directory that is nonstandard to
      read-tree command, outside a "negative" test in the t1004 test
      script.
      
      This patch is the first step to untangle this mess.
      
      The next step would be to teach read-tree, merge-recursive and
      clean (in C) to use setup_standard_excludes().
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      039bc64e
  20. 30 Oct, 2007 1 commit
    • Lars Knoll's avatar
      Speedup scanning for excluded files. · 68492fc7
      Lars Knoll authored
      Try to avoid a lot of work scanning for excluded files,
      by caching some more information when setting up the exclusion
      data structure.
      
      Speeds up 'git runstatus' on a repository containing the Qt sources by 30% and
      reduces the amount of instructions executed (as measured by valgrind) by a
      factor of 2.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      68492fc7
  21. 30 Sep, 2007 1 commit
  22. 01 Aug, 2007 1 commit
  23. 13 Jun, 2007 2 commits
    • Jeff King's avatar
      builtin-add: simplify (and increase accuracy of) exclude handling · e96980ef
      Jeff King authored
      Previously, the code would always set up the excludes, and then manually
      pick through the pathspec we were given, assuming that non-added but
      existing paths were just ignored. This was mostly correct, but would
      erroneously mark a totally empty directory as 'ignored'.
      
      Instead, we now use the collect_ignored option of dir_struct, which
      unambiguously tells us whether a path was ignored. This simplifies the
      code, and means empty directories are now just not mentioned at all.
      
      Furthermore, we now conditionally ask dir_struct to respect excludes,
      depending on whether the '-f' flag has been set. This means we don't have
      to pick through the result, checking for an 'ignored' flag; ignored entries
      were either added or not in the first place.
      
      We can safely get rid of the special 'ignored' flags to dir_entry, which
      were not used anywhere else.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJonas Fonseca <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e96980ef
    • Jeff King's avatar
      dir_struct: add collect_ignored option · 2abd31b0
      Jeff King authored
      When set, this option will cause read_directory to keep
      track of which entries were ignored. While this shouldn't
      effect functionality in most cases, it can make warning
      messages to the user much more useful.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2abd31b0
  24. 22 May, 2007 1 commit
  25. 12 Apr, 2007 1 commit
    • Linus Torvalds's avatar
      Teach directory traversal about subprojects · 09595258
      Linus Torvalds authored
      This is the promised cleaned-up version of teaching directory traversal
      (ie the "read_directory()" logic) about subprojects. That makes "git add"
      understand to add/update subprojects.
      
      It now knows to look at the index file to see if a directory is marked as
      a subproject, and use that as information as whether it should be recursed
      into or not.
      
      It also generally cleans up the handling of directory entries when
      traversing the working tree, by splitting up the decision-making process
      into small functions of their own, and adding a fair number of comments.
      
      Finally, it teaches "add_file_to_cache()" that directory names can have
      slashes at the end, since the directory traversal adds them to make the
      difference between a file and a directory clear (it always did that, but
      my previous too-ugly-to-apply subproject patch had a totally different
      path for subproject directories and avoided the slash for that case).
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      09595258
  26. 01 Apr, 2007 1 commit
    • Linus Torvalds's avatar
      Optimize directory listing with pathspec limiter. · 9fc42d60
      Linus Torvalds authored
      The way things are set up, you can now pass a "pathspec" to the
      "read_directory()" function. If you pass NULL, it acts exactly
      like it used to do (read everything). If you pass a non-NULL
      pointer, it will simplify it into a "these are the prefixes
      without any special characters", and stop any readdir() early if
      the path in question doesn't match any of the prefixes.
      
      NOTE! This does *not* obviate the need for the caller to do the *exact*
      pathspec match later. It's a first-level filter on "read_directory()", but
      it does not do the full pathspec thing. Maybe it should. But in the
      meantime, builtin-add.c really does need to do first
      
      	read_directory(dir, .., pathspec);
      	if (pathspec)
      		prune_directory(dir, pathspec, baselen);
      
      ie the "prune_directory()" part will do the *exact* pathspec pruning,
      while the "read_directory()" will use the pathspec just to do some quick
      high-level pruning of the directories it will recurse into.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9fc42d60
  27. 29 Dec, 2006 2 commits
    • Junio C Hamano's avatar
      Fix 'git add' with .gitignore · 4d06f8ac
      Junio C Hamano authored
      When '*.ig' is ignored, and you have two files f.ig and d.ig/foo
      in the working tree,
      
      	$ git add .
      
      correctly ignored f.ig but failed to ignore d.ig/foo.  This was
      caused by a thinko in an earlier commit 4888c534, when we tried
      to allow adding otherwise ignored files.
      
      After reverting that commit, this takes a much simpler approach.
      When we have an unmatched pathspec that talks about an existing
      pathname, we know it is an ignored path the user tried to add,
      so we include it in the set of paths directory walker returned.
      
      This does not let you say "git add -f D" on an ignored directory
      D and add everything under D.  People can submit a patch to
      further allow it if they want to, but I think it is a saner
      behaviour to require explicit paths to be spelled out in such a
      case.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      4d06f8ac
    • Junio C Hamano's avatar
      Revert "read_directory: show_both option." · c889763b
      Junio C Hamano authored
      This reverts commit 4888c534.
      c889763b
  28. 25 Dec, 2006 2 commits
  29. 06 Dec, 2006 1 commit
  30. 08 Sep, 2006 1 commit
  31. 19 May, 2006 1 commit
  32. 17 May, 2006 1 commit