kmx git

Commit	Date	Message
f0e693b1	2021-09-07T17:53:49	str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
af3088e4	2018-06-29T11:45:15	refspec: rename `git_refspec__free` to `git_refspec__dispose` Since commit 630a67366 (refspec: add public parsing api, 2018-02-07), we now have two functions `git_refspec_free` and `git_refspec__free`. The difference is that the first one will free the structure itself, while the second one will only free the structure's contents. Use our new `dispose` naming pattern for the latter function to help avoid confusion.
0c7f49dd	2017-06-30T13:39:01	Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
f28e4c97	2014-04-01T20:17:49	refspec: git_refspec_parse() does not exist
bf522e08	2014-01-26T16:59:36	refspec: move to git_buf for outputting strings
af613ecd	2013-10-28T23:30:45	remote: store dwimed refspecs separately This allows us to add e.g. "HEAD" as a refspec when none are given without overwriting the user's data.
d8488457	2013-04-28T16:26:55	remote: dwim the refspecs according to the remote's advertised refs As git allows you to store shorthand refspecs in the configuration, we need to do this ourselves.
1be680c4	2013-04-20T19:13:47	refspec: unify the string and parsed data It used to be separate as an attempt to make the querying easier, but it didn't work out that way, so put all the data together. Add git_refspec_string() as well to get the original string, which is now stored alongside the independent parts.
4330ab26	2013-04-20T04:43:28	remote: handle multiple refspecs A remote can have a multitude of refspecs. Up to now our git_remote's have supported a single one for each fetch and push out of simplicity to get something working. Let the remotes and internal code know about multiple remotes and get the tests passing with them. Instead of setting a refspec, the external users can clear all and add refspecs. This should be enough for most uses, though we're still missing a querying function.
359fc2d2	2013-01-08T17:07:25	update copyrights
b0f6e45d	2012-11-01T15:47:18	create FETCH_HEAD specially instead of as a ref file
fb39b3a5	2012-10-02T14:36:59	refspec: introduce git_refspec__serialize()
3e012fca	2012-09-26T19:15:11	refspec: introduce git_refspec_transform_l()
3230a44f	2012-09-30T10:56:06	remote: support downloading all tags Also honor remote.$name.tagopt = --tags.
3665ba8e	2012-09-27T12:04:41	refspec: add git_refspec__free, remove git_refspec_parse The latter shouldn't be exposed and isn't used, git_refspec__parse supersedes it. Fix a leak in the refspec tests while we're at it.
0adfa20a	2012-09-11T11:42:13	refspec: introduce git_refspec__parse()
e172cf08	2012-05-18T01:21:06	errors: Rename the generic return codes
5e0de328	2012-02-13T17:10:24	Update Copyright header Signed-off-by: schu <schu-github@schulog.org>
97769280	2011-11-30T11:27:15	Use git_buf for path storage instead of stack-based buffers This converts virtually all of the places that allocate GIT_PATH_MAX buffers on the stack for manipulating paths to use git_buf objects instead. The patch is pretty careful not to touch the public API for libgit2, so there are a few places that still use GIT_PATH_MAX. This extends and changes some details of the git_buf implementation to add a couple of extra functions and to make error handling easier. This includes serious alterations to all the path.c functions, and several of the fileops.c ones, too. Also, there are a number of new functions that parallel existing ones except that use a git_buf instead of a stack-based buffer (such as git_config_find_global_r that exists alongsize git_config_find_global). This also modifies the win32 version of p_realpath to allocate whatever buffer size is needed to accommodate the realpath instead of hardcoding a GIT_PATH_MAX limit, but that change needs to be tested still.
dc9e960f	2011-10-09T02:59:01	refspec: make the structure more complete Add a next pointer to make it a linked list and add the 'pattern' and 'matching' flags. Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
bb742ede	2011-09-19T01:54:32	Cleanup legal data 1. The license header is technically not valid if it doesn't have a copyright signature. 2. The COPYING file has been updated with the different licenses used in the project. 3. The full GPLv2 header in each file annoys me.
9c82357b	2011-06-17T18:13:14	Add a remotes API Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

f0e693b1

2021-09-07T17:53:49

str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.

af3088e4

2018-06-29T11:45:15

refspec: rename `git_refspec__free` to `git_refspec__dispose` Since commit 630a67366 (refspec: add public parsing api, 2018-02-07), we now have two functions `git_refspec_free` and `git_refspec__free`. The difference is that the first one will free the structure itself, while the second one will only free the structure's contents. Use our new `dispose` naming pattern for the latter function to help avoid confusion.

0c7f49dd

2017-06-30T13:39:01

Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.

f28e4c97

2014-04-01T20:17:49

refspec: git_refspec_parse() does not exist

bf522e08

2014-01-26T16:59:36

refspec: move to git_buf for outputting strings

af613ecd

2013-10-28T23:30:45

remote: store dwimed refspecs separately This allows us to add e.g. "HEAD" as a refspec when none are given without overwriting the user's data.

d8488457

2013-04-28T16:26:55

remote: dwim the refspecs according to the remote's advertised refs As git allows you to store shorthand refspecs in the configuration, we need to do this ourselves.

1be680c4

2013-04-20T19:13:47

refspec: unify the string and parsed data It used to be separate as an attempt to make the querying easier, but it didn't work out that way, so put all the data together. Add git_refspec_string() as well to get the original string, which is now stored alongside the independent parts.

4330ab26

2013-04-20T04:43:28

remote: handle multiple refspecs A remote can have a multitude of refspecs. Up to now our git_remote's have supported a single one for each fetch and push out of simplicity to get something working. Let the remotes and internal code know about multiple remotes and get the tests passing with them. Instead of setting a refspec, the external users can clear all and add refspecs. This should be enough for most uses, though we're still missing a querying function.

359fc2d2

2013-01-08T17:07:25

update copyrights

b0f6e45d

2012-11-01T15:47:18

create FETCH_HEAD specially instead of as a ref file

fb39b3a5

2012-10-02T14:36:59

refspec: introduce git_refspec__serialize()

3e012fca

2012-09-26T19:15:11

refspec: introduce git_refspec_transform_l()

3230a44f

2012-09-30T10:56:06

remote: support downloading all tags Also honor remote.$name.tagopt = --tags.

3665ba8e

2012-09-27T12:04:41

refspec: add git_refspec__free, remove git_refspec_parse The latter shouldn't be exposed and isn't used, git_refspec__parse supersedes it. Fix a leak in the refspec tests while we're at it.

0adfa20a

2012-09-11T11:42:13

refspec: introduce git_refspec__parse()

e172cf08

2012-05-18T01:21:06

errors: Rename the generic return codes

5e0de328

2012-02-13T17:10:24

Update Copyright header Signed-off-by: schu <schu-github@schulog.org>

97769280

2011-11-30T11:27:15

Use git_buf for path storage instead of stack-based buffers This converts virtually all of the places that allocate GIT_PATH_MAX buffers on the stack for manipulating paths to use git_buf objects instead. The patch is pretty careful not to touch the public API for libgit2, so there are a few places that still use GIT_PATH_MAX. This extends and changes some details of the git_buf implementation to add a couple of extra functions and to make error handling easier. This includes serious alterations to all the path.c functions, and several of the fileops.c ones, too. Also, there are a number of new functions that parallel existing ones except that use a git_buf instead of a stack-based buffer (such as git_config_find_global_r that exists alongsize git_config_find_global). This also modifies the win32 version of p_realpath to allocate whatever buffer size is needed to accommodate the realpath instead of hardcoding a GIT_PATH_MAX limit, but that change needs to be tested still.

dc9e960f

2011-10-09T02:59:01

refspec: make the structure more complete Add a next pointer to make it a linked list and add the 'pattern' and 'matching' flags. Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

bb742ede

2011-09-19T01:54:32

Cleanup legal data 1. The license header is technically not valid if it doesn't have a copyright signature. 2. The COPYING file has been updated with the different licenses used in the project. 3. The full GPLv2 header in each file annoys me.

9c82357b

2011-06-17T18:13:14

Add a remotes API Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

thodg/libgit2/src/refspec.h

src/refspec.h

Log