1. 10 Jun, 2019 2 commits
  2. 07 Jun, 2019 1 commit
  3. 06 Jun, 2019 1 commit
    • ignore: handle escaped trailing whitespace · d81e7866
      The gitignore's pattern format specifies that "Trailing spaces
      are ignored unless they are quoted with backslash ("\")". We do
      not honor this currently and will treat a pattern "foo\ " as if
      it was "foo\" only and a pattern "foo\ \ " as "foo\ \".
      
      Fix our code to handle those special cases and add tests to avoid
      regressions.
      Patrick Steinhardt committed
  4. 05 Jun, 2019 1 commit
    • online tests: use gitlab for auth failures · e66a4eb3
      GitHub recently changed their behavior from returning 401s for private
      or nonexistent repositories on a clone to returning 404s.  For our tests
      that require an auth failure (and 401), move to GitLab to request a
      missing repository.  This lets us continue to test our auth failure
      case, at least until they decide to mimic that decision.
      Edward Thomson committed
  5. 24 May, 2019 4 commits
  6. 22 May, 2019 1 commit
    • config: validate quoted section value · 23c5699e
      When we reach a whitespace after a section name, we assume that what
      will follow will be a quoted subsection name.  Pass the current position
      of the line being parsed to the subsection parser, so that it can
      validate that subsequent characters are additional whitespace or a
      single quote.
      
      Previously we would begin parsing after the section name, looking for
      the first quotation mark.  This allows invalid characters to embed
      themselves between the end of the section name and the first quotation
      mark, eg `[section foo "subsection"]`, which is illegal.
      Edward Thomson committed
  7. 21 May, 2019 1 commit
  8. 19 May, 2019 10 commits
  9. 10 May, 2019 1 commit
  10. 03 May, 2019 1 commit
  11. 30 Apr, 2019 1 commit
  12. 26 Apr, 2019 3 commits
    • refspec: fix transforming nested stars · 0c71e4cb
      When we transform a refspec with a component containing a glob, then
      we simply copy over the component until the next separator from
      the matching ref. E.g. if we have a ref "refs/heads/foo/bar" and
      a refspec "refs/heads/*/bar:refs/remotes/origin/*/bar", we:
      
      1. Copy over everything until hitting the glob from the <dst>
         part: "refs/remotes/origin/".
      2. Strip the common prefix of ref and <src> part until the glob,
         which is "refs/heads/". This leaves us with a ref of "foo/bar".
      3. Copy from the ref until the next "/" separator, resulting in
         "refs/remotes/origin/foo".
      4. Copy over the remaining part of the <dst> spec, which is
         "bar": "refs/remotes/origin/foo/bar".
      
      This worked just fine in a world where globs in refspecs were
      restricted such that a globbing component may only contain a
      single "*", only. But this restriction has been lifted, so that a
      glob component may be nested between other characters, causing
      the above algorithm to fail. Most notably the third step, where
      we copy until hitting the next "/" separator, might result in a
      wrong transformation. Given e.g. a ref "refs/gbranchg/head" and a
      refspec "refs/g*g/head:refs/remotes/origin/*", we'd also be
      copying the "g" between "branch" and "/" and end up with the
      wrong transformed ref "refs/remotes/origin/branchg".
      
      Instead of copying until the next component separator, we should
      copy until we hit the pattern after the "*". So in the above
      example, we'd copy until hitting the string "g/head".
      Patrick Steinhardt committed
    • refs: loosen restriction on wildcard "*" refspecs · 51214b85
      In commit cd377f45c9 (refs: loosen restriction on wildcard "*"
      refspecs, 2015-07-22) in git.git, the restrictions on wildcard
      "*" refspecs has been loosened. While wildcards were previously
      only allowed if the component is a single "*", this was changed
      to also accept other patterns as part of the component.
      
      We never adapted to that change and still reject any wildcard
      patterns that aren't a single "*" only. Update our tests to
      reflect the upstream change and adjust our own code accordingly.
      Patrick Steinhardt committed
  13. 21 Apr, 2019 1 commit
  14. 17 Apr, 2019 1 commit
    • git_repository_init: stop traversing at windows root · 45f24e78
      Stop traversing the filesystem at the Windows directory root.  We were
      calculating the filesystem root for the given directory to create, and
      walking up the filesystem hierarchy.  We intended to stop when the
      traversal path length is equal to the root path length (ie, stopping at
      the root, since no path may be shorter than the root path).
      
      However, on Windows, the root path may be specified in two different
      ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter.
      `git_path_dirname_r` returns the path _without_ a trailing slash, even
      for the Windows root.  As a result, during traversal, we need to test
      that the traversal path is _less than or equal to_ the root path length
      to determine if we've hit the root to ensure that we stop when our
      traversal path is `Z:` and our calculated root path was `Z:\`.
      Edward Thomson committed
  15. 06 Apr, 2019 1 commit
  16. 05 Apr, 2019 1 commit
    • ignore: treat paths with trailing "/" as directories · 9d117e20
      The function `git_ignore_path_is_ignored` is there to test the
      ignore status of paths that need not necessarily exist inside of
      a repository. This has the implication that for a given path, we
      cannot always decide whether it references a directory or a file,
      and we need to distinguish those cases because ignore rules may
      treat those differently. E.g. given the following gitignore file:
      
          *
          !/**/
      
      we'd only want to unignore directories, while keeping files
      ignored. But still, calling `git_ignore_path_is_ignored("dir/")`
      will say that this directory is ignored because it treats "dir/"
      as a file path.
      
      As said, the `is_ignored` function cannot always decide whether
      the given path is a file or directory, and thus it may produce
      wrong results in some cases. While this is unfixable in the
      general case, we can do better when we are being passed a path
      name with a trailing path separator (e.g. "dir/") and always
      treat them as directories.
      Patrick Steinhardt committed
  17. 04 Apr, 2019 1 commit
  18. 29 Mar, 2019 5 commits
  19. 20 Mar, 2019 1 commit
  20. 15 Mar, 2019 1 commit
  21. 14 Mar, 2019 1 commit