1. 29 Jun, 2021 1 commit
  2. 15 Jun, 2019 2 commits
    • global: convert trivial `fnmatch` users to use `wildcard` · de70bb46
      Upstream git.git has converted its codebase to use wildcard in
      favor of fnmatch in commit 70a8fc999d (stop using fnmatch (either
      native or compat), 2014-02-15). To keep our own regex-matching in
      line with what git does, convert all trivial instances of
      `fnmatch` usage to use `wildcard`, instead. Trivial usage is
      defined to be use of `fnmatch` with either no flags or flags that
      have a 1:1 equivalent in wildmatch (PATHNAME, IGNORECASE).
      Patrick Steinhardt committed
    • posix: remove implicit include of "fnmatch.h" · 451df793
      We're about to phase out our bundled fnmatch implementation as
      git.git has moved to wildmatch long ago in 2014. To make it
      easier to spot which files are stilll using fnmatch, remove the
      implicit "fnmatch.h" include in "posix.h" and instead include it
      explicitly.
      Patrick Steinhardt committed
  3. 26 Apr, 2019 1 commit
    • 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
  4. 22 Jan, 2019 1 commit
  5. 17 Jan, 2019 1 commit
  6. 13 Jul, 2018 1 commit
    • treewide: remove use of C++ style comments · 9994cd3f
      C++ style comment ("//") are not specified by the ISO C90 standard and
      thus do not conform to it. While libgit2 aims to conform to C90, we did
      not enforce it until now, which is why quite a lot of these
      non-conforming comments have snuck into our codebase. Do a tree-wide
      conversion of all C++ style comments to the supported C style comments
      to allow us enforcing strict C90 compliance in a later commit.
      Patrick Steinhardt committed
  7. 29 Jun, 2018 1 commit
  8. 25 Jun, 2018 1 commit
  9. 22 Jun, 2018 1 commit
  10. 10 Jun, 2018 1 commit
  11. 20 Apr, 2018 1 commit
  12. 03 Jul, 2017 1 commit
    • 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
  13. 04 Aug, 2016 1 commit
    • refspec: do not set empty rhs for fetch refspecs · 1eee631d
      According to git-fetch(1), "[t]he colon can be omitted when <dst>
      is empty." So according to git, the refspec "refs/heads/master"
      is the same as the refspec "refs/heads/master:" when fetching
      changes. When trying to fetch from a remote with a trailing
      colon with libgit2, though, the fetch actually fails while it
      works when the trailing colon is left out. So obviously, libgit2
      does _not_ treat these two refspec formats the same for fetches.
      
      The problem results from parsing refspecs, where the resulting
      refspec has its destination set to an empty string in the case of
      a trailing colon and to a `NULL` pointer in the case of no
      trailing colon. When passing this to our DWIM machinery, the
      empty string gets translated to "refs/heads/", which is simply
      wrong.
      
      Fix the problem by having the parsing machinery treat both cases
      the same for fetch refspecs.
      Patrick Steinhardt committed
  14. 23 Feb, 2016 1 commit
  15. 30 Jun, 2015 1 commit
  16. 22 May, 2015 1 commit
  17. 10 Mar, 2015 1 commit
  18. 09 Nov, 2014 1 commit
    • push: use the common refspec parser · aad638f3
      There is one well-known and well-tested parser which we should use,
      instead of implementing parsing a second time.
      
      The common parser is also augmented to copy the LHS into the RHS if the
      latter is empty.
      
      The expressions test had to change a bit, as we now catch a bad RHS of a
      refspec locally.
      Carlos Martín Nieto committed
  19. 21 Aug, 2014 1 commit
  20. 17 Aug, 2014 1 commit
  21. 04 Jul, 2014 2 commits
  22. 27 Jan, 2014 1 commit
  23. 01 Nov, 2013 1 commit
  24. 01 Jul, 2013 1 commit
  25. 30 Apr, 2013 1 commit
  26. 28 Apr, 2013 1 commit
  27. 20 Apr, 2013 2 commits
    • refspec: unify the string and parsed data · 1be680c4
      It used to be separate as an attempt to make the querying easier, but
      it didn't work out that way, so put all the data together.
      
      Add git_refspec_string() as well to get the original string, which is
      now stored alongside the independent parts.
      Carlos Martín Nieto committed
    • remote: handle multiple refspecs · 4330ab26
      A remote can have a multitude of refspecs. Up to now our git_remote's
      have supported a single one for each fetch and push out of simplicity
      to get something working.
      
      Let the remotes and internal code know about multiple remotes and get
      the tests passing with them.
      
      Instead of setting a refspec, the external users can clear all and add
      refspecs. This should be enough for most uses, though we're still
      missing a querying function.
      Carlos Martín Nieto committed
  28. 11 Feb, 2013 2 commits
  29. 11 Jan, 2013 1 commit
  30. 08 Jan, 2013 1 commit
  31. 11 Nov, 2012 1 commit
  32. 25 Oct, 2012 1 commit
  33. 07 Oct, 2012 1 commit
  34. 30 Sep, 2012 1 commit
  35. 25 Sep, 2012 1 commit
  36. 29 May, 2012 1 commit