kmx git

Commit	Date	Message
51eff5a5	2020-05-29T13:13:19	strarray: we should `dispose` instead of `free` We _dispose_ the contents of objects; we _free_ objects (and their contents). Update `git_strarray_free` to be `git_strarray_dispose`. `git_strarray_free` remains as a deprecated proxy function.
93a9044f	2020-01-31T08:49:34	fetchhead: strip credentials from remote URL If fetching from an anonymous remote via its URL, then the URL gets written into the FETCH_HEAD reference. This is mainly done to give valuable context to some commands, like for example git-merge(1), which will put the URL into the generated MERGE_MSG. As a result, what gets written into FETCH_HEAD may become public in some cases. This is especially important considering that URLs may contain credentials, e.g. when cloning 'https://foo:bar@example.com/repo' we persist the complete URL into FETCH_HEAD and put it without any kind of sanitization into the MERGE_MSG. This is obviously bad, as your login data has now just leaked as soon as you do git-push(1). When writing the URL into FETCH_HEAD, upstream git does strip credentials first. Let's do the same by trying to parse the remote URL as a "real" URL, removing any credentials and then re-formatting the URL. In case this fails, e.g. when it's a file path or not a valid URL, we just fall back to using the URL as-is without any sanitization. Add tests to verify our behaviour.
e54343a4	2019-06-29T09:17:32	fileops: rename to "futils.h" to match function signatures Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
e48dbdf9	2019-05-20T05:51:44	fetchhead: use size_t in tests
ecf4f33a	2018-02-08T11:14:48	Convert usage of `git_buf_free` to new `git_buf_dispose`
30a876cd	2016-10-27T11:29:15	tests: fetchhead: fix memory leak
1eee631d	2016-08-04T13:45:28	refspec: do not set empty rhs for fetch refspecs 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.
35a8a8c5	2015-04-22T17:29:20	remote: move the tagopt setting to the fetch options This is another option which we should not be keeping in the remote, but is specific to each particular operation.
8f0104ec	2015-04-21T22:10:36	Remove the callbacks struct from the remote Having the setting be different from calling its actions was not a great idea and made for the sake of the wrong convenience. Instead of that, accept either fetch options, push options or the callbacks when dealing with the remote. The fetch options are currently only the callbacks, but more options will be moved from setters and getters on the remote to the options. This does mean passing the same struct along the different functions but the typical use-case will only call git_remote_fetch() or git_remote_push() and so won't notice much difference.
659cf202	2015-01-07T12:23:05	Remove the signature from ref-modifying functions The signature for the reflog is not something which changes dynamically. Almost all uses will be NULL, since we want for the repository's default identity to be used, making it noise. In order to allow for changing the identity, we instead provide git_repository_set_ident() and git_repository_ident() which allow a user to override the choice of signature.
209425ce	2014-11-08T13:25:51	remote: rename _load() to _lookup() This brings it in line with the rest of the lookup functions.
9c206a22	2014-06-06T15:24:53	remote: use active refspec override in the tests This lets us test this bit as well as getting closer to what they were trying to do.
3f894205	2014-06-06T15:01:45	remote: allow overriding the refspecs for download and fetch With opportunistic ref updates, git has introduced the concept of having base refspecs and refspecs that are active for a particular fetch. Let's start by letting the user override the refspecs for download.
d908351a	2014-09-05T22:31:53	When auto follow tags, FETCH_HEAD should list only newly followed tags
c3ab1e5a	2014-02-04T20:38:13	Add reflog parameters to remote apis Also added a test for git_remote_fetch.
17820381	2013-11-14T14:05:52	Rename tests-clar to tests

51eff5a5

2020-05-29T13:13:19

strarray: we should `dispose` instead of `free` We _dispose_ the contents of objects; we _free_ objects (and their contents). Update `git_strarray_free` to be `git_strarray_dispose`. `git_strarray_free` remains as a deprecated proxy function.

93a9044f

2020-01-31T08:49:34

fetchhead: strip credentials from remote URL If fetching from an anonymous remote via its URL, then the URL gets written into the FETCH_HEAD reference. This is mainly done to give valuable context to some commands, like for example git-merge(1), which will put the URL into the generated MERGE_MSG. As a result, what gets written into FETCH_HEAD may become public in some cases. This is especially important considering that URLs may contain credentials, e.g. when cloning 'https://foo:bar@example.com/repo' we persist the complete URL into FETCH_HEAD and put it without any kind of sanitization into the MERGE_MSG. This is obviously bad, as your login data has now just leaked as soon as you do git-push(1). When writing the URL into FETCH_HEAD, upstream git does strip credentials first. Let's do the same by trying to parse the remote URL as a "real" URL, removing any credentials and then re-formatting the URL. In case this fails, e.g. when it's a file path or not a valid URL, we just fall back to using the URL as-is without any sanitization. Add tests to verify our behaviour.

e54343a4

2019-06-29T09:17:32

fileops: rename to "futils.h" to match function signatures Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.

e48dbdf9

2019-05-20T05:51:44

fetchhead: use size_t in tests

ecf4f33a

2018-02-08T11:14:48

Convert usage of `git_buf_free` to new `git_buf_dispose`

30a876cd

2016-10-27T11:29:15

tests: fetchhead: fix memory leak

1eee631d

2016-08-04T13:45:28

refspec: do not set empty rhs for fetch refspecs 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.

35a8a8c5

2015-04-22T17:29:20

remote: move the tagopt setting to the fetch options This is another option which we should not be keeping in the remote, but is specific to each particular operation.

8f0104ec

2015-04-21T22:10:36

Remove the callbacks struct from the remote Having the setting be different from calling its actions was not a great idea and made for the sake of the wrong convenience. Instead of that, accept either fetch options, push options or the callbacks when dealing with the remote. The fetch options are currently only the callbacks, but more options will be moved from setters and getters on the remote to the options. This does mean passing the same struct along the different functions but the typical use-case will only call git_remote_fetch() or git_remote_push() and so won't notice much difference.

659cf202

2015-01-07T12:23:05

Remove the signature from ref-modifying functions The signature for the reflog is not something which changes dynamically. Almost all uses will be NULL, since we want for the repository's default identity to be used, making it noise. In order to allow for changing the identity, we instead provide git_repository_set_ident() and git_repository_ident() which allow a user to override the choice of signature.

209425ce

2014-11-08T13:25:51

remote: rename _load() to _lookup() This brings it in line with the rest of the lookup functions.

9c206a22

2014-06-06T15:24:53

remote: use active refspec override in the tests This lets us test this bit as well as getting closer to what they were trying to do.

3f894205

2014-06-06T15:01:45

remote: allow overriding the refspecs for download and fetch With opportunistic ref updates, git has introduced the concept of having base refspecs *and* refspecs that are active for a particular fetch. Let's start by letting the user override the refspecs for download.

d908351a

2014-09-05T22:31:53

When auto follow tags, FETCH_HEAD should list only newly followed tags

c3ab1e5a

2014-02-04T20:38:13

Add reflog parameters to remote apis Also added a test for git_remote_fetch.

17820381

2013-11-14T14:05:52

Rename tests-clar to tests

thodg/libgit2/tests/online/fetchhead.c

tests/online/fetchhead.c

Log