src/refspec.c


Log

Author Commit Date CI Message
punkymaniac 379c4646 2021-09-09T19:49:04 Fix coding style for pointer Make some syntax change to follow coding style.
Edward Thomson 89ee31a8 2020-04-05T19:35:19 refspec: use GIT_ASSERT
Edward Thomson cb4bfbc9 2020-04-05T11:07:54 buffer: git_buf_sanitize should return a value `git_buf_sanitize` is called with user-input, and wants to sanity-check that input. Allow it to return a value if the input was malformed in a way that we cannot cope.
Edward Thomson 68e35588 2020-10-11T13:35:35 refspec: return GIT_EINVALIDSPEC for invalid specs Disambiguate invalid specifications in `git_refspec__parse` so that callers can determine the difference between invalid specifications and actual errors. No call sites wil propagagte this new error message to an end-user, so there is no user-facing API change.
Edward Thomson d70979cf 2020-10-11T12:26:34 refs: error checking in internal name validation Move `git_reference__is_valid_name` to `git_reference__name_is_valid`, which returns errors and sets an out boolean parameter.
Patrick Steinhardt de70bb46 2019-06-13T15:27:22 global: convert trivial `fnmatch` users to use `wildcard` Upstream git.git has converted its codebase to use wildcard in favor of fnmatch in commit 70a8fc999d (stop using fnmatch (either native or compat), 2014-02-15). To keep our own regex-matching in line with what git does, convert all trivial instances of `fnmatch` usage to use `wildcard`, instead. Trivial usage is defined to be use of `fnmatch` with either no flags or flags that have a 1:1 equivalent in wildmatch (PATHNAME, IGNORECASE).
Patrick Steinhardt 451df793 2019-06-13T15:20:23 posix: remove implicit include of "fnmatch.h" We're about to phase out our bundled fnmatch implementation as git.git has moved to wildmatch long ago in 2014. To make it easier to spot which files are stilll using fnmatch, remove the implicit "fnmatch.h" include in "posix.h" and instead include it explicitly.
Patrick Steinhardt 0c71e4cb 2019-04-26T10:38:02 refspec: fix transforming nested stars When we transform a refspec with a component containing a glob, then we simply copy over the component until the next separator from the matching ref. E.g. if we have a ref "refs/heads/foo/bar" and a refspec "refs/heads/*/bar:refs/remotes/origin/*/bar", we: 1. Copy over everything until hitting the glob from the <dst> part: "refs/remotes/origin/". 2. Strip the common prefix of ref and <src> part until the glob, which is "refs/heads/". This leaves us with a ref of "foo/bar". 3. Copy from the ref until the next "/" separator, resulting in "refs/remotes/origin/foo". 4. Copy over the remaining part of the <dst> spec, which is "bar": "refs/remotes/origin/foo/bar". This worked just fine in a world where globs in refspecs were restricted such that a globbing component may only contain a single "*", only. But this restriction has been lifted, so that a glob component may be nested between other characters, causing the above algorithm to fail. Most notably the third step, where we copy until hitting the next "/" separator, might result in a wrong transformation. Given e.g. a ref "refs/gbranchg/head" and a refspec "refs/g*g/head:refs/remotes/origin/*", we'd also be copying the "g" between "branch" and "/" and end up with the wrong transformed ref "refs/remotes/origin/branchg". Instead of copying until the next component separator, we should copy until we hit the pattern after the "*". So in the above example, we'd copy until hitting the string "g/head".
Edward Thomson f673e232 2018-12-27T13:47:34 git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson ed8cfbf0 2019-01-17T00:32:31 references: use new names in internal usage Update internal usage to use the `git_reference` names for constants.
Patrick Steinhardt 9994cd3f 2018-06-25T11:56:52 treewide: remove use of C++ style comments C++ style comment ("//") are not specified by the ISO C90 standard and thus do not conform to it. While libgit2 aims to conform to C90, we did not enforce it until now, which is why quite a lot of these non-conforming comments have snuck into our codebase. Do a tree-wide conversion of all C++ style comments to the supported C style comments to allow us enforcing strict C90 compliance in a later commit.
Patrick Steinhardt 8a00de08 2018-07-06T10:47:06 Merge pull request #4699 from nelhage/fetch-null-dst git_refspec_transform: Handle NULL dst
Patrick Steinhardt 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.
Nelson Elhage 786c6470 2018-06-25T02:05:21 git_refspec_transform: Handle NULL dst
cynecx 630a6736 2018-02-07T22:30:27 refspec: add public parsing api Fix typo Fix some type issues More fixes Address requested changes Add test Fix naming Fix condition and tests Address requested changes Fix typo
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Etienne Samson 592b200c 2018-04-18T21:41:44 refspec: check for valid parameters in git_refspec__dwim_one CID:1383993, "In git_refspec__dwim_one: All paths that lead to this null pointer comparison already dereference the pointer earlier (CWE-476)"
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt b9f28b8d 2016-02-23T10:09:03 refspec: check buffer with GITERR_CHECK_ALLOC_BUF
Jeff Hostetler 64e6b5b0 2015-06-29T17:32:22 fix memory leak in refspec.c on errors.
Carlos Martín Nieto 7cd4ba1b 2015-05-22T12:11:42 refspec: make sure matching refspecs have src, dst and input strings When we find out that we're dealing with a matching refspec, we set the flag and return immediately. This leaves the strings as NULL, which breaks the contract. Assign these pointers to a string with the correct values.
Adrien Thebo b523194d 2015-03-04T13:29:13 refspec: set err message on invalid refspec If a refspec could not be parsed, the git_refspec__parse function would return an error value but would not provide additional error information for the callers. This commit amends that function to set a more useful error message.
Carlos Martín Nieto aad638f3 2014-11-07T15:00:11 push: use the common refspec parser There is one well-known and well-tested parser which we should use, instead of implementing parsing a second time. The common parser is also augmented to copy the LHS into the RHS if the latter is empty. The expressions test had to change a bit, as we now catch a bad RHS of a refspec locally.
Jacques Germishuys 8f6073f6 2014-08-21T18:53:43 Check that the refspec matches before modifying the out buffer
Jacques Germishuys 4e53c280 2014-08-17T14:55:06 Check if the refspec matches before transforming
Carlos Martín Nieto f5287fa6 2014-07-04T17:17:23 refspec: support asterisks in the middle of a pattern We used to assume a refspec would only have an asterisk in the middle of their respective pattern. This has not been a valid assumption for some time now with git. Instead of assuming where the asterisk is going to be, change the logic to treat each pattern as having two halves with a replacement bit in the middle, where the asterisk is.
Carlos Martín Nieto 9ed104a8 2014-07-04T17:16:17 refspec: short-circuit non-pattern refspecs on transform When transforming a non-pattern refspec, we simply need to copy over the opposite string. Move that logic up to the wrapper so we can assume a pattern refspec in the transformation function.
Carlos Martín Nieto bf522e08 2014-01-26T16:59:36 refspec: move to git_buf for outputting strings
Carlos Martín Nieto 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.
Russell Belfer 55ededfd 2013-07-01T10:21:14 Make refspec_transform paranoid about arguments
Carlos Martín Nieto 8d39f2a7 2013-04-30T10:55:17 refspec: add direction accessor
Carlos Martín Nieto 528a4e24 2013-04-28T14:16:45 Parse shorthand refspecs as valid Relax the ONELEVEL ref naming rules so the refspec parsing code can ask for 'master' to be considered valid.
Carlos Martín Nieto 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.
Carlos Martín Nieto 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.
Jameson Miller db4bb415 2013-02-07T14:53:52 Teach refspec to transform destination reference to source reference
Jameson Miller 2e3e8c88 2013-02-08T11:05:47 Teach remote branch to return its remote
nulltoken a379e652 2013-01-11T16:14:17 refspec: prevent git_refspec__free() from segfaulting Fix libgit2/libgit2sharp#247
Edward Thomson 359fc2d2 2013-01-08T17:07:25 update copyrights
Edward Thomson b0f6e45d 2012-11-01T15:47:18 create FETCH_HEAD specially instead of as a ref file
nulltoken fb39b3a5 2012-10-02T14:36:59 refspec: introduce git_refspec__serialize()
nulltoken 3e012fca 2012-09-26T19:15:11 refspec: introduce git_refspec_transform_l()
Carlos Martín Nieto 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.
nulltoken 0adfa20a 2012-09-11T11:42:13 refspec: introduce git_refspec__parse()
nulltoken d05e2c64 2012-05-30T00:27:22 refspec: expose the force update specifier through git_refspec_force() accessor
Vicent Martí 904b67e6 2012-05-18T01:48:50 errors: Rename error codes
Vicent Martí e172cf08 2012-05-18T01:21:06 errors: Rename the generic return codes
Vicent Martí 3fbcac89 2012-05-02T19:56:38 Remove old and unused error codes
Vicent Martí b8802146 2012-05-01T19:16:14 Merge remote-tracking branch 'carlosmn/remaining-errors' into new-error-handling Conflicts: src/refspec.c
nulltoken fa6420f7 2012-04-29T21:46:33 buf: deploy git_buf_len()
Carlos Martín Nieto 3aa351ea 2012-04-26T15:05:07 error handling: move the missing parts over to the new error handling
Vicent Martí cb8a7961 2012-03-07T00:02:55 error-handling: Repository This also includes droping `git_buf_lasterror` because it makes no sense in the new system. Note that in most of the places were it has been dropped, the code needs cleanup. I.e. GIT_ENOMEM is going away, so instead it should return a generic `-1` and obviously not throw anything.
schu 5e0de328 2012-02-13T17:10:24 Update Copyright header Signed-off-by: schu <schu-github@schulog.org>
Carlos Martín Nieto 279afd2a 2012-01-31T17:21:49 refspec: a ref name includes the refs/ prefix git_refspec_transform_r assumed that the reference name passed would be only a branch or tag name. This is not the case, and we need to take into consideration what's in the refspec's source to know how much of the prefix to ignore.
nulltoken c3ec2ec2 2012-01-19T00:09:47 transport: prevent git_remote_download() from segfaulting when being passed a lightweight remote built with git_remote_new()
Russell Belfer 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.
Carlos Martín Nieto 0ca7ca3e 2011-10-09T03:07:53 refspec: allow a simple branchname A simple branchname as refspec is valid and we shouldn't throw an error when encountering one. Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
Vicent Marti 3286c408 2011-10-28T14:51:13 global: Properly use `git__` memory wrappers Ensure that all memory related functions (malloc, calloc, strdup, free, etc) are using their respective `git__` wrappers.
Carlos Martín Nieto 4a3b18a6 2011-10-03T22:26:06 A missing refspec is not an error It's rare for a configured remote, but for one given as an URL on the command line, it's more often than not the case. Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
Vicent Marti 87d9869f 2011-09-19T03:34:49 Tabify everything There were quite a few places were spaces were being used instead of tabs. Try to catch them all. This should hopefully not break anything. Except for `git blame`. Oh well.
Vicent Marti 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.
Carlos Martín Nieto 63f91e1c 2011-06-22T16:52:30 Add git.git's fnmatch, which is really GNU's and the git__fnmatch wrapper If the strings match, git__fnmatch returns GIT_SUCCESS and GIT_ENOMATCH on failure to match. MSVC fixes: Added a test for _MSC_VER and (in that case) defined HAVE_STRING_H to 1 so it doesn't try to include <strings.h> which doesn't exist in the MSVC world. Moved the function declarations to use the modern inline ones so MSVC doesn't have a fit. Added casts everywhere so MSVC doesn't crap its pants. Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
Carlos Martín Nieto 92cb6aa9 2011-06-23T15:41:29 Add git_refspec_transform Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
Carlos Martín Nieto 9c82357b 2011-06-17T18:13:14 Add a remotes API Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>