thodg/libgit2

Diff

  • Show log

    Commit

  • Hash : fa59f18d
    Author : Vicent Marti
    Date : 2011-05-09T20:54:04

    Change error handling mechanism once again 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");

  • README.md

  • libgit2 - the Git linkable library

    libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language with bindings.

    libgit2 is licensed under a very permissive license (GPLv2 with a special Linking Exception). This basically means that you can link it (unmodified) with any kind of software without having to release its source code.

    What It Can Do

    libgit2 is already very usable.

    • SHA conversions, formatting and shortening
    • object reading (loose and packed)
    • object writing (loose)
    • commit, tag, tree and blob parsing and write-back
    • tree traversal
    • revision walking
    • index file (staging area) manipulation
    • custom ODB backends
    • reference management (including packed references)
    • …and more

    Building libgit2 - External dependencies

    libgit2 builds cleanly on most platforms without any external dependencies. Under Unix-like systems, like Linux, *BSD and Mac OS X, libgit2 expects pthreads to be available; they should be installed by default on all systems. Under Windows, libgit2 uses the native Windows API for threading.

    Additionally, he following libraries may be used as replacement for built-in functionality:

    libgit2 can be built using the SHA1 implementation of LibSSL-Crypto, instead of the built-in custom implementations. Performance wise, they are quite similar.

    Building libgit2 - Using waf

    Waf is a minimalist build system which only requires a Python 2.5+ interpreter to run. This is the default build system for libgit2.

    To build libgit2 using waf, first configure the build system by running:

    $ ./waf configure

    Then build the library, either in its shared (libgit2.so) or static form (libgit2.a):

    $ ./waf build-static
$ ./waf build-shared

    You can then run the full test suite with:

    $ ./waf test

    And finally you can install the library with (you may need to sudo):

    $ sudo ./waf install

    The waf build system for libgit2 accepts the following flags:

    --debug
    build the library with debug symbols.
    Defaults to off.

--sha1=[builtin|ppc|openssl]
    use the builtin SHA1 functions, the optimized PPC versions
    or the SHA1 functions from LibCrypto (OpenSSL).
    Defaults to 'builtin'.

--msvc=[7.1|8.0|9.0|10.0]
    Force a specific version of the MSVC compiler, if more than
    one version is installed.

--arch=[ia64|x64|x86|x86_amd64|x86_ia64]
    Force a specific architecture for compilers that support it.

--with-sqlite
    Enable sqlite support.

    You can run ./waf --help to see a full list of install options and targets.

    Building libgit2 - Using CMake

    The libgit2 library can also be built using CMake 2.6+ (http://www.cmake.org) on all platforms.

    On most systems you can build the library using the following commands

    $ mkdir build && cd build
$ cmake ..
$ cmake --build .

    Alternatively you can point the CMake GUI tool to the CMakeLists.txt file and generate platform specific build project or IDE workspace.

    To install the library you can specify the install prefix by setting:

    $ cmake .. -DCMAKE_INSTALL_PREFIX=/install/prefix
$ cmake --build . --target install

    For more advanced use or questions about CMake please read http://www.cmake.org/Wiki/CMake_FAQ.

    Language Bindings

    Here are the bindings to libgit2 that are currently available:

    If you start another language binding to libgit2, please let us know so we can add it to the list.

    How Can I Contribute

    Fork libgit2/libgit2 on GitHub, add your improvement, push it to a branch in your fork named for the topic, send a pull request.

    You can also file bugs or feature requests under the libgit2 project on GitHub, or join us on the mailing list by sending an email to:

    libgit2@librelist.com

    License

    libgit2 is under GPL2 with linking exemption. This means you can link to the library with any program, commercial, open source or other. However, you cannot modify libgit2 and distribute it without supplying the source.

    See the COPYING file for the full license text.

kmx.io     mail     discord kmxgit v0.4.0