1. 07 Jun, 2011 2 commits
  2. 05 Jun, 2011 3 commits
  3. 23 May, 2011 2 commits
  4. 09 May, 2011 1 commit
    • Change error handling mechanism once again · fa59f18d
      Ok, this is the real deal. Hopefully. Here's how it's going to work:
      
      - One main method, called `git__throw`, that sets the error
      	code and error message when an error happens.
      
      	This method must be called in every single place where an error
      	code was being returned previously, setting an error message
      	instead.
      
      	Example, instead of:
      
      		return GIT_EOBJCORRUPTED;
      
      	Use:
      
      		return git__throw(GIT_EOBJCORRUPTED,
      			"The object is missing a finalizing line feed");
      
      	And instead of:
      
      		[...] {
      			error = GIT_EOBJCORRUPTED;
      			goto cleanup;
      		}
      
      	Use:
      
      		[...] {
      			error = git__throw(GIT_EOBJCORRUPTED, "What an error!");
      			goto cleanup;
      		}
      
      	The **only** exception to this are the allocation methods, which
      	return NULL on failure but already set the message manually.
      
      		/* only place where an error code can be returned directly,
      		   because the error message has already been set by the wrapper */
      		if (foo == NULL)
      			return GIT_ENOMEM;
      
      - One secondary method, called `git__rethrow`, which can be used to
      fine-grain an error message and build an error stack.
      
      	Example, instead of:
      
      		if ((error = foobar(baz)) < GIT_SUCCESS)
      			return error;
      
      	You can now do:
      
      		if ((error = foobar(baz)) < GIT_SUCCESS)
      			return git__rethrow(error, "Failed to do a major operation");
      
      	The return of the `git_lasterror` method will be a string in the
      	shape of:
      
      		"Failed to do a major operation. (Failed to do an internal
      		operation)"
      
      	E.g.
      
      		"Failed to open the index. (Not enough permissions to access
      		'/path/to/index')."
      
      	NOTE: do not abuse this method. Try to write all `git__throw`
      	messages in a descriptive manner, to avoid having to rethrow them to
      	clarify their meaning.
      
      	This method should only be used in the places where the original
      	error message set by a subroutine is not specific enough.
      
      	It is encouraged to continue using this style as much possible to
      	enforce error propagation:
      
      		if ((error = foobar(baz)) < GIT_SUCCESS)
      			return error; /* `foobar` has set an error message, and
      							 we are just propagating it */
      
      The error handling revamp will take place in two phases:
      
      	- Phase 1: Replace all pieces of code that return direct error codes
      	with calls to `git__throw`. This can be done semi-automatically
      	using `ack` to locate all the error codes that must be replaced.
      
      	- Phase 2: Add some `git__rethrow` calls in those cases where the
      	original error messages are not specific enough.
      
      Phase 1 is the main goal. A minor libgit2 release will be shipped once
      Phase 1 is ready, and the work will start on gradually improving the
      error handling mechanism by refining specific error messages.
      
      OTHER NOTES:
      
      	- When writing error messages, please refrain from using weasel
      	words. They add verbosity to the message without giving any real
      	information. (<3 Emeric)
      
      	E.g.
      
      		"The reference file appears to be missing a carriage return"
      			Nope.
      
      		"The reference file is missing a carriage return"
      			Yes.
      
      	- When calling `git__throw`, please try to use more generic error
      	codes so we can eventually reduce the list of error codes to
      	something more reasonable. Feel free to add new, more generic error
      	codes if these are going to replace several of the old ones.
      
      	E.g.
      
      		return GIT_EREFCORRUPTED;
      
      	Can be turned into:
      
      		return git__throw(GIT_EOBJCORRUPTED,
      			"The reference is corrupted");
      Vicent Marti committed
  5. 01 May, 2011 1 commit
  6. 29 Apr, 2011 1 commit
    • refs: don't loose info on resolve error · 68a146c1
      Typical use is git_reference_resolve(&ref, ref). Currently, if there is
      an error, ref will point to NULL, causing the user to lose that
      reference.
      
      Always update resolved_ref instead of just on finding an OID ref,
      storing the last valid reference in it.
      
      This change helps simplify the code for allowing root commits.
      
      Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
      Carlos Martín Nieto committed
  7. 26 Apr, 2011 1 commit
  8. 21 Apr, 2011 1 commit
  9. 13 Apr, 2011 1 commit
  10. 08 Apr, 2011 1 commit
  11. 29 Mar, 2011 5 commits
  12. 25 Mar, 2011 1 commit
    • New external API method: `git_reference_listcb` · 09e8de0f
      List all the references in the repository, calling a custom
      callback for each one.
      
      The listed references may be filtered by type, or using
      a bitwise OR of several types. Use the magic value
      `GIT_REF_LISTALL` to obtain all references, including
      packed ones.
      
      The `callback` function will be called for each of the references
      in the repository, and will receive the name of the reference and
      the `payload` value passed to this method.
      Vicent Marti committed
  13. 22 Mar, 2011 1 commit
  14. 16 Mar, 2011 1 commit
  15. 15 Mar, 2011 3 commits
  16. 14 Mar, 2011 2 commits
    • Fix the retarded object interdependency system · 6b2a1941
      It's no longer retarded. All object interdependencies are stored as OIDs
      instead of actual objects. This should be hundreds of times faster,
      specially on big repositories. Heck, who knows, maye it doesn't even
      segfault -- wouldn't that be awesome?
      
      What has changed on the API?
      
      	`git_commit_parent`, `git_commit_tree`, `git_tag_target` now return
      	their values through a pointer-to-pointer, and have an error code.
      
      	`git_commit_set_tree` and `git_tag_set_target` now return an error
      	code and may fail.
      
      	`git_repository_free__no_gc` has been deprecated because it's
      	stupid. Since there are no longer any interdependencies between
      	objects, we don't need internal reference counting, and GC
      	never fails or double-free's pointers.
      
      	`git_object_close` now does a very sane thing: marks an object
      	as unused. Closed objects will be eventually free'd from the
      	object cache based on LRU. Please use `git_object_close` from
      	the garbage collector `destroy` method on your bindings. It's
      	100% safe.
      
      	`git_repository_gc` is a new method that forces a garbage collector
      	pass through the repo, to free as many LRU objects as possible.
      	This is useful if we are running out of memory.
      Vicent Marti committed
    • Add new method `git_reference_listall` · 00571828
      Lists all the references in a repository. Listing may be filtered by
      reference type.
      
      This should applease Lord Clem.
      Vicent Marti committed
  17. 05 Mar, 2011 1 commit
  18. 04 Mar, 2011 1 commit
  19. 03 Mar, 2011 11 commits