1. 15 Jun, 2015 1 commit
  2. 24 Mar, 2015 1 commit
  3. 03 Mar, 2015 3 commits
  4. 15 Feb, 2015 1 commit
  5. 13 Feb, 2015 3 commits
  6. 27 Oct, 2014 1 commit
  7. 30 Sep, 2014 1 commit
    • Introduce reference transactions · ab8d9242
      A transaction allows you to lock multiple references and set up changes
      for them before applying the changes all at once (or as close as the
      backend supports).
      
      This can be used for replication purposes, or for making sure some
      operations run when the reference is locked and thus cannot be changed.
      Carlos Martín Nieto committed
  8. 30 May, 2014 2 commits
  9. 03 Apr, 2014 1 commit
  10. 17 Mar, 2014 1 commit
  11. 10 Feb, 2014 1 commit
  12. 05 Feb, 2014 7 commits
  13. 03 Feb, 2014 1 commit
  14. 02 Feb, 2014 1 commit
  15. 30 Jan, 2014 3 commits
  16. 15 Jan, 2014 1 commit
  17. 13 Jan, 2014 1 commit
  18. 02 Jan, 2014 2 commits
  19. 11 Dec, 2013 5 commits
    • Further callback error check style fixes · f10d7a36
      Okay, I've decided I like the readability of this style much
      better so I used it everywhere.
      Russell Belfer committed
    • Remove converting user error to GIT_EUSER · 25e0b157
      This changes the behavior of callbacks so that the callback error
      code is not converted into GIT_EUSER and instead we propagate the
      return value through to the caller.  Instead of using the
      giterr_capture and giterr_restore functions, we now rely on all
      functions to pass back the return value from a callback.
      
      To avoid having a return value with no error message, the user
      can call the public giterr_set_str or some such function to set
      an error message.  There is a new helper 'giterr_set_callback'
      that functions can invoke after making a callback which ensures
      that some error message was set in case the callback did not set
      one.
      
      In places where the sign of the callback return value is
      meaningful (e.g. positive to skip, negative to abort), only the
      negative values are returned back to the caller, obviously, since
      the other values allow for continuing the loop.
      
      The hardest parts of this were in the checkout code where positive
      return values were overloaded as meaningful values for checkout.
      I fixed this by adding an output parameter to many of the internal
      checkout functions and removing the overload.  This added some
      code, but it is probably a better implementation.
      
      There is some funkiness in the network code where user provided
      callbacks could be returning a positive or a negative value and
      we want to rely on that to cancel the loop.  There are still a
      couple places where an user error might get turned into GIT_EUSER
      there, I think, though none exercised by the tests.
      Russell Belfer committed
    • Further EUSER and error propagation fixes · dab89f9b
      This continues auditing all the places where GIT_EUSER is being
      returned and making sure to clear any existing error using the
      new giterr_user_cancel helper.  As a result, places that relied
      on intercepting GIT_EUSER but having the old error preserved also
      needed to be cleaned up to correctly stash and then retrieve the
      actual error.
      
      Additionally, as I encountered places where error codes were not
      being propagated correctly, I tried to fix them up.  A number of
      those fixes are included in the this commit as well.
      Russell Belfer committed
    • Improve GIT_EUSER handling · 96869a4e
      This adds giterr_user_cancel to return GIT_EUSER and clear any
      error message that is sitting around.  As a result of using that
      in places, we need to be more thorough with capturing errors that
      happen inside a callback when used internally.  To help with that,
      this also adds giterr_capture and giterr_restore so that when we
      internally use a foreach-type function that clears errors and
      converts them to GIT_EUSER, it is easier to restore not just the
      return value, but the actual error message text.
      Russell Belfer committed
  20. 09 Dec, 2013 2 commits
  21. 23 Nov, 2013 1 commit
    • reflog: integrate into the ref writing · a57dd3b7
      Whenever a reference is created or updated, we need to write to the
      reflog regardless of whether the user gave us a message, so we shouldn't
      leave that to the ref frontend, but integrate it into the backend.
      
      This also eliminates the race between ref update and writing to the
      reflog, as we protect the reflog with the ref lock.
      
      As an additional benefit, this reflog append on the backend happens by
      appending to the file instead of parsing and rewriting it.
      Carlos Martín Nieto committed