1. 06 Jun, 2018 1 commit
    • ignore: fix negative leading directory rules unignoring subdirectory files · 20b4c175
      When computing whether a file is ignored, we simply search for the first
      matching rule and return whether it is a positive ignore rule (the file
      is really ignored) or whether it is a negative ignore rule (the file is
      being unignored). Each rule has a set of flags which are being passed to
      `fnmatch`, depending on what kind of rule it is. E.g. in case it is a
      negative ignore we add a flag `GIT_ATTR_FNMATCH_NEGATIVE`, in case it
      contains a glob we set the `GIT_ATTR_FNMATCH_HASGLOB` flag.
      
      One of these flags is the `GIT_ATTR_FNMATCH_LEADINGDIR` flag, which is
      always set in case the pattern has a trailing "/*" or in case the
      pattern is negative. The flag causes the `fnmatch` function to return a
      match in case a string is a leading directory of another, e.g. "dir/"
      matches "dir/foo/bar.c". In case of negative patterns, this is wrong in
      certain cases.
      
      Take the following simple example of a gitignore:
      
          dir/
          !dir/
      
      The `LEADINGDIR` flag causes "!dir/" to match "dir/foo/bar.c", and we
      correctly unignore the directory. But take this example:
      
          *.test
          !dir/*
      
      We expect everything in "dir/" to be unignored, but e.g. a file in a
      subdirectory of dir should be ignored, as the "*" does not cross
      directory hierarchies. With `LEADINGDIR`, though, we would just see that
      "dir/" matches and return that the file is unignored, even if it is
      contained in a subdirectory. Instead, we want to ignore leading
      directories here and check "*.test". Afterwards, we have to iterate up
      to the parent directory and do the same checks.
      
      To fix the issue, disallow matching against leading directories in
      gitignore files. This can be trivially done by just adding the
      `GIT_ATTR_FNMATCH_NOLEADINGDIR` to the spec passed to
      `git_attr_fnmatch__parse`. Due to a bug in that function, though, this
      flag is being ignored for negative patterns, which is fixed in this
      commit, as well. As a last fix, we need to ignore rules that are
      supposed to match a directory when our path itself is a file.
      
      All together, these changes fix the described error case.
      Patrick Steinhardt committed
  2. 12 Apr, 2018 1 commit
    • attr_file: fix handling of directory patterns with trailing spaces · 251d8771
      When comparing whether a path matches a directory rule, we pass the
      both the path and directory name to `fnmatch` with
      `GIT_ATTR_FNMATCH_DIRECTORY` being set. `fnmatch` expects the pattern to
      contain no trailing directory '/', which is why we try to always strip
      patterns of trailing slashes. We do not handle that case correctly
      though when the pattern itself has trailing spaces, causing the match to
      fail.
      
      Fix the issue by stripping trailing spaces and tabs for a rule previous
      to checking whether the pattern is a directory pattern with a trailing
      '/'. This replaces the whitespace-stripping in our ignore file parsing
      code, which was stripping whitespaces too late. Add a test to catch
      future breakage.
      Patrick Steinhardt committed
  3. 03 Jul, 2017 2 commits
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
    • Add missing license headers · 2480d0eb
      Some implementation files were missing the license headers. This commit
      adds them.
      Patrick Steinhardt committed
  4. 17 May, 2017 1 commit
  5. 29 Dec, 2016 1 commit
  6. 09 Feb, 2016 1 commit
  7. 28 Oct, 2015 1 commit
  8. 12 May, 2015 4 commits
    • attr: less path mangling during attribute matching · 90997e40
      When handling attr matching, simply compare the directory path where the
      attribute file resides to the path being matched.  Skip over commonality
      to allow us to compare the contents of the attribute file to the remainder
      of the path.
      
      This allows us to more easily compare the pattern directly to the path,
      instead of trying to guess whether we want to compare the path's basename
      or the full path based on whether the match was inside a containing
      directory or not.
      
      This also allows us to do fewer translations on the pattern (trying to
      re-prefix it.)
      Edward Thomson committed
    • attr: don't mangle file path during attr matching · 9465bedb
      When determining whether some file matches an attr pattern, do
      not try to truncate the path to pass to fnmatch.  When there is
      no containing directory for an item (eg, from a .gitignore in the
      root) this will cause us to truncate our path, which means that
      we cannot do meaningful comparisons on it and we may have false
      positives when trying to determine whether a given file is actually
      a file or a folder (as we have lost the path's base information.)
      
      This mangling was to allow fnmatch to compare a directory on disk to
      the name of a directory, but it is unnecessary as our fnmatch accepts
      FNM_LEADING_DIR.
      Edward Thomson committed
    • attr: don't match files for folders · ef6d0722
      When ignoring a path "foo/", ensure that this is actually a directory,
      and not simply a file named "foo".
      Edward Thomson committed
  9. 28 Apr, 2015 1 commit
  10. 23 Apr, 2015 1 commit
  11. 04 Feb, 2015 2 commits
  12. 03 Feb, 2015 1 commit
    • attrcache: don't re-read attrs during checkout · 9f779aac
      During checkout, assume that the .gitattributes files aren't
      modified during the checkout.  Instead, create an "attribute session"
      during checkout.  Assume that attribute data read in the same
      checkout "session" hasn't been modified since the checkout started.
      (But allow subsequent checkouts to invalidate the cache.)
      
      Further, cache nonexistent git_attr_file data even when .gitattributes
      files are not found to prevent re-scanning for nonexistent files.
      Edward Thomson committed
  13. 29 Dec, 2014 1 commit
  14. 21 Nov, 2014 1 commit
    • attr_file: Do not assume ODB data is NULL-terminated · 72d00241
      That's a bad assumption to make, even though right now it holds
      (because of the way we've implemented decompression of packfiles),
      this may change in the future, given that ODB objects can be
      binary data.
      
      Furthermore, the ODB object can return a NULL pointer if the object
      is empty. Copying the NULL pointer to the strbuf lets us handle it
      like an empty string. Again, the NULL pointer is valid behavior because
      you're supposed to check the *size* of the object before working
      on it.
      Vicent Marti committed
  15. 06 Nov, 2014 1 commit
    • ignore: don't leak rules into higher directories · 6069042f
      A rule "src" in src/.gitignore must only match subdirectories of
      src/. The current code does not include this context in the match rule
      and would thus consider this rule to match the top-level src/ directory
      instead of the intended src/src/.
      
      Keep track fo the context in which the rule was defined so we can
      perform a prefix match.
      Carlos Martín Nieto committed
  16. 05 Nov, 2014 1 commit
  17. 08 Aug, 2014 2 commits
  18. 06 May, 2014 1 commit
    • Improve checks for ignore containment · f554611a
      The diff code was using an "ignored_prefix" directory to track if
      a parent directory was ignored that contained untracked files
      alongside tracked files. Unfortunately, when negative ignore rules
      were used for directories inside ignored parents, the wrong rules
      were applied to untracked files inside the negatively ignored
      child directories.
      
      This commit moves the logic for ignore containment into the workdir
      iterator (which is a better place for it), so the ignored-ness of
      a directory is contained in the frame stack during traversal.  This
      allows a child directory to override with a negative ignore and yet
      still restore the ignored state of the parent when we traverse out
      of the child.
      
      Along with this, there are some problems with "directory only"
      ignore rules on container directories.  Given "a/*" and "!a/b/c/"
      (where the second rule is a directory rule but the first rule is
      just a generic prefix rule), then the directory only constraint
      was having "a/b/c/d/file" match the first rule and not the second.
      This was fixed by having ignore directory-only rules test a rule
      against the prefix of a file with LEADINGDIR enabled.
      
      Lastly, spot checks for ignores using `git_ignore_path_is_ignored`
      were tested from the top directory down to the bottom to deal with
      the containment problem, but this is wrong. We have to test bottom
      to top so that negative subdirectory rules will be checked before
      parent ignore rules.
      
      This does change the behavior of some existing tests, but it seems
      only to bring us more in line with core Git, so I think those
      changes are acceptable.
      Russell Belfer committed
  19. 21 Apr, 2014 1 commit
  20. 18 Apr, 2014 3 commits
    • Minor fixes · ac16bd0a
      Only apply LEADING_DIR pattern munging to patterns in ignore and
      attribute files, not to pathspecs used to select files to operate
      on.  Also, allow internal macro definitions to be evaluated before
      loading all external ones (important so that external ones can
      make use of internal `binary` definition).
      Russell Belfer committed
    • Fix ignore difference from git with trailing /* · 916fcbd6
      Ignore patterns that ended with a trailing '/*' were still needing
      to match against another actual '/' character in the full path.
      This is not the same behavior as core Git.
      
      Instead, we strip a trailing '/*' off of any patterns that were
      matching and just take it to imply the FNM_LEADING_DIR behavior.
      Russell Belfer committed
    • Preload attribute files that may contain macros · e3a2a04c
      There was a latent bug where files that use macro definitions
      could be parsed before the macro definitions were loaded.  Because
      of attribute file caching, preloading files that are going to be
      used doesn't add a significant amount of overhead, so let's always
      preload any files that could contain macros before we assemble the
      actual vector of files to scan for attributes.
      Russell Belfer committed
  21. 17 Apr, 2014 5 commits
  22. 14 Apr, 2014 1 commit
    • Fix core.excludesfile named .gitignore · a9528b8f
      Ignore rules with slashes in them are matched using FNM_PATHNAME
      and use the path to the .gitignore file from the root of the
      repository along with the path fragment (including slashes) in
      the ignore file itself.  Unfortunately, the relative path to the
      .gitignore file was being applied to the global core.excludesfile
      if that was also named ".gitignore".
      
      This fixes that with more precise matching and includes test for
      ignore rules with leading slashes (which were the primary example
      of this being broken in the real world).
      
      This also backports an improvement to the file context logic from
      the threadsafe-iterators branch where we don't rely on mutating
      the key of the attribute file name to generate the context path.
      Russell Belfer committed
  23. 19 Sep, 2013 1 commit
  24. 09 Aug, 2013 1 commit
    • Revert PR #1462 and provide alternative fix · 4ba64794
      This rolls back the changes to fnmatch parsing from commit
      2e40a60e except for the tests
      that were added.  Instead this adds couple of new flags that can
      be passed in when attempting to parse an fnmatch pattern.  Also,
      this changes the pathspec match logic to special case matching a
      filename with a '!' prefix against a negative pattern.
      
      This fixes the build.
      Russell Belfer committed
  25. 20 Jun, 2013 1 commit
    • Add status flags to force output sort order · 22b6b82f
      Files in status will, be default, be sorted according to the case
      insensitivity of the filesystem that we're running on.  However,
      in some cases, this is not desirable.  Even on case insensitive
      file systems, 'git status' at the command line will generally use
      a case sensitive sort (like 'ls').  Some GUIs prefer to display a
      list of file case insensitively even on case-sensitive platforms.
      
      This adds two new flags: GIT_STATUS_OPT_SORT_CASE_SENSITIVELY
      and GIT_STATUS_OPT_SORT_CASE_INSENSITIVELY that will override the
      default sort order of the status output and give the user control.
      This includes tests for exercising these new options and makes
      the examples/status.c program emulate core Git and always use a
      case sensitive sort.
      Russell Belfer committed
  26. 29 May, 2013 1 commit
  27. 15 Apr, 2013 1 commit
  28. 11 Apr, 2013 1 commit