Commit 39fd7646 by Alex Good

Merge branch 'main' into respect-force-flag-in-remote-fetch

parents 8ad5998f e1674766
......@@ -104,7 +104,8 @@ Getting Help
**Chat with us**
- via IRC: join [#libgit2](https://webchat.freenode.net/#libgit2) on Freenode
- via IRC: join [#libgit2](https://web.libera.chat/#libgit2) on
[libera](https://libera.chat).
- via Slack: visit [slack.libgit2.org](http://slack.libgit2.org/) to sign up,
then join us in `#libgit2`
......
......@@ -35,7 +35,7 @@ easily accessible permanent record of the conversation.
## Libgit2 Versions
The `master` branch is the main branch where development happens.
The `main` branch is the main branch where development happens.
Releases are tagged
(e.g. [v0.21.0](https://github.com/libgit2/libgit2/releases/tag/v0.21.0) )
and when a critical bug fix needs to be backported, it will be done on a
......@@ -51,7 +51,7 @@ commit SHA
Using [`git describe`](http://git-scm.com/docs/git-describe) is a
great way to tell us what version you're working with.
If you're not running against the latest `master` branch version,
If you're not running against the latest `main` branch version,
please compile and test against that to avoid re-reporting an issue that's
already been fixed.
......@@ -68,11 +68,11 @@ flow](https://guides.github.com/introduction/flow/index.html), where
contributors fork the [libgit2 repository](https://github.com/libgit2/libgit2),
make their changes on branch, and submit a
[Pull Request](https://help.github.com/articles/using-pull-requests)
(a.k.a. "PR"). Pull requests should usually be targeted at the `master`
(a.k.a. "PR"). Pull requests should usually be targeted at the `main`
branch.
Life will be a lot easier for you (and us) if you follow this pattern
(i.e. fork, named branch, submit PR). If you use your fork's `master`
(i.e. fork, named branch, submit PR). If you use your fork's `main`
branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
......
# Releasing the library
We have three kinds of releases: "full" releases, maintenance releases and security releases. Full ones release the state of the `master` branch whereas maintenance releases provide bugfixes building on top of the currently released series. Security releases are also for the current series but only contain security fixes on top of the previous release.
We have three kinds of releases: "full" releases, maintenance releases and security releases. Full ones release the state of the `main` branch whereas maintenance releases provide bugfixes building on top of the currently released series. Security releases are also for the current series but only contain security fixes on top of the previous release.
## Full release
......@@ -40,7 +40,7 @@ followed by the three sections in the changelog. For release candidates we can a
During the freeze, and certainly after the first release candidate, any bindings the core team work with should be updated in order to discover any issues that might come up with the multitude of approaches to memory management, embedding or linking.
Create a branch `maint/v0.X` at the current state of `master` after you've created the tag. This will be used for maintenance releases and lets our dependents track the latest state of the series.
Create a branch `maint/v0.X` at the current state of `main` after you've created the tag. This will be used for maintenance releases and lets our dependents track the latest state of the series.
## Maintenance release
......@@ -76,7 +76,7 @@ We use docurium to generate our documentation. It is a tool written in ruby whic
gem install docurium
and run it against our description file with the tip of master checked out.
and run it against our description file with the tip of `main` checked out.
cm doc api.docurium
......
......@@ -100,6 +100,7 @@ GIT_EXTERN(int) git_apply_options_init(git_apply_options *opts, unsigned int ver
* @param preimage the tree to apply the diff to
* @param diff the diff to apply
* @param options the options for the apply (or null for defaults)
* @return 0 or an error code
*/
GIT_EXTERN(int) git_apply_to_tree(
git_index **out,
......@@ -137,6 +138,7 @@ typedef enum {
* @param diff the diff to apply
* @param location the location to apply (workdir, index or both)
* @param options the options for the apply (or null for defaults)
* @return 0 or an error code
*/
GIT_EXTERN(int) git_apply(
git_repository *repo,
......
......@@ -356,6 +356,11 @@ typedef enum {
* >
* > - `ciphers` is the list of ciphers that are eanbled.
*
* * opts(GIT_OPT_GET_USER_AGENT, git_buf *out)
*
* > Get the value of the User-Agent header.
* > The User-Agent is written to the `out` buffer.
*
* * opts(GIT_OPT_ENABLE_OFS_DELTA, int enabled)
*
* > Enable or disable the use of "offset deltas" when creating packfiles,
......
......@@ -702,7 +702,7 @@ GIT_EXTERN(int) git_index_update_all(
* @param at_pos the address to which the position of the index entry is written (optional)
* @param index an existing index object
* @param path path to search
* @return a zero-based position in the index if found; GIT_ENOTFOUND otherwise
* @return 0 or an error code
*/
GIT_EXTERN(int) git_index_find(size_t *at_pos, git_index *index, const char *path);
......@@ -713,7 +713,7 @@ GIT_EXTERN(int) git_index_find(size_t *at_pos, git_index *index, const char *pat
* @param at_pos the address to which the position of the index entry is written (optional)
* @param index an existing index object
* @param prefix the prefix to search for
* @return 0 with valid value in at_pos; an error code otherwise
* @return 0 or an error code
*/
GIT_EXTERN(int) git_index_find_prefix(size_t *at_pos, git_index *index, const char *prefix);
......
......@@ -51,7 +51,7 @@ typedef struct git_indexer_progress {
* Type for progress callbacks during indexing. Return a value less
* than zero to cancel the indexing or download.
*
* @param stats Structure containing information about the state of the tran sfer
* @param stats Structure containing information about the state of the transfer
* @param payload Payload provided by caller
*/
typedef int GIT_CALLBACK(git_indexer_progress_cb)(const git_indexer_progress *stats, void *payload);
......@@ -64,6 +64,7 @@ typedef struct git_indexer_options {
/** progress_cb function to call with progress information */
git_indexer_progress_cb progress_cb;
/** progress_cb_payload payload for the progress callback */
void *progress_cb_payload;
......
......@@ -334,6 +334,7 @@ GIT_EXTERN(int) git_treebuilder_insert(
*
* @param bld Tree builder
* @param filename Filename of the entry to remove
* @return 0 or an error code
*/
GIT_EXTERN(int) git_treebuilder_remove(
git_treebuilder *bld, const char *filename);
......@@ -463,6 +464,7 @@ typedef struct {
* @param baseline the tree to base these changes on
* @param nupdates the number of elements in the update list
* @param updates the list of updates to perform
* @return 0 or an error code
*/
GIT_EXTERN(int) git_tree_create_updated(git_oid *out, git_repository *repo, git_tree *baseline, size_t nupdates, const git_tree_update *updates);
......
......@@ -297,14 +297,15 @@ int git_odb__hashlink(git_oid *out, const char *path)
GIT_ERROR_CHECK_ALLOC(link_data);
read_len = p_readlink(path, link_data, size);
link_data[size] = '\0';
if (read_len != size) {
if (read_len == -1) {
git_error_set(GIT_ERROR_OS, "failed to read symlink data for '%s'", path);
git__free(link_data);
return -1;
}
GIT_ASSERT(read_len <= size);
link_data[read_len] = '\0';
result = git_odb_hash(out, link_data, size, GIT_OBJECT_BLOB);
result = git_odb_hash(out, link_data, read_len, GIT_OBJECT_BLOB);
git__free(link_data);
} else {
int fd = git_futils_open_ro(path);
......
......@@ -52,6 +52,10 @@
# define WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_3 0x00002000
#endif
#ifndef WINHTTP_NO_CLIENT_CERT_CONTEXT
# define WINHTTP_NO_CLIENT_CERT_CONTEXT NULL
#endif
#ifndef HTTP_STATUS_PERMANENT_REDIRECT
# define HTTP_STATUS_PERMANENT_REDIRECT 308
#endif
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment