1. 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
  2. 23 Feb, 2016 1 commit
  3. 30 Jun, 2015 1 commit
  4. 22 May, 2015 1 commit
  5. 10 Mar, 2015 1 commit
  6. 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
  7. 21 Aug, 2014 1 commit
  8. 17 Aug, 2014 1 commit
  9. 04 Jul, 2014 2 commits
  10. 27 Jan, 2014 1 commit
  11. 01 Nov, 2013 1 commit
  12. 01 Jul, 2013 1 commit
  13. 30 Apr, 2013 1 commit
  14. 28 Apr, 2013 1 commit
  15. 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
  16. 11 Feb, 2013 2 commits
  17. 11 Jan, 2013 1 commit
  18. 08 Jan, 2013 1 commit
  19. 11 Nov, 2012 1 commit
  20. 25 Oct, 2012 1 commit
  21. 07 Oct, 2012 1 commit
  22. 30 Sep, 2012 1 commit
  23. 25 Sep, 2012 1 commit
  24. 29 May, 2012 1 commit
  25. 17 May, 2012 2 commits
  26. 03 May, 2012 1 commit
  27. 30 Apr, 2012 1 commit
  28. 26 Apr, 2012 1 commit
  29. 06 Mar, 2012 1 commit
    • error-handling: Repository · cb8a7961
      This also includes droping `git_buf_lasterror` because it makes no sense
      in the new system. Note that in most of the places were it has been
      dropped, the code needs cleanup. I.e. GIT_ENOMEM is going away, so
      instead it should return a generic `-1` and obviously not throw
      anything.
      Vicent Martí committed
  30. 13 Feb, 2012 1 commit
  31. 31 Jan, 2012 1 commit
  32. 18 Jan, 2012 1 commit
  33. 08 Dec, 2011 1 commit
    • Use git_buf for path storage instead of stack-based buffers · 97769280
      This converts virtually all of the places that allocate GIT_PATH_MAX
      buffers on the stack for manipulating paths to use git_buf objects
      instead.  The patch is pretty careful not to touch the public API
      for libgit2, so there are a few places that still use GIT_PATH_MAX.
      
      This extends and changes some details of the git_buf implementation
      to add a couple of extra functions and to make error handling easier.
      
      This includes serious alterations to all the path.c functions, and
      several of the fileops.c ones, too.  Also, there are a number of new
      functions that parallel existing ones except that use a git_buf
      instead of a stack-based buffer (such as git_config_find_global_r
      that exists alongsize git_config_find_global).
      
      This also modifies the win32 version of p_realpath to allocate whatever
      buffer size is needed to accommodate the realpath instead of hardcoding
      a GIT_PATH_MAX limit, but that change needs to be tested still.
      Russell Belfer committed
  34. 18 Nov, 2011 1 commit
  35. 29 Oct, 2011 1 commit
  36. 08 Oct, 2011 1 commit