summaryrefslogtreecommitdiff
path: root/src/refspec.c
Commit message (Collapse)AuthorAgeFilesLines
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-171-37/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix coding style for pointerpunkymaniac2021-09-091-1/+1
| | | | Make some syntax change to follow coding style.
* refspec: use GIT_ASSERTEdward Thomson2020-11-271-9/+18
|
* buffer: git_buf_sanitize should return a valueEdward Thomson2020-11-251-3/+14
| | | | | | `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.
* refspec: return GIT_EINVALIDSPEC for invalid specsEdward Thomson2020-10-251-4/+5
| | | | | | | 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.
* refs: error checking in internal name validationEdward Thomson2020-10-251-28/+43
| | | | | Move `git_reference__is_valid_name` to `git_reference__name_is_valid`, which returns errors and sets an out boolean parameter.
* global: convert trivial `fnmatch` users to use `wildcard`Patrick Steinhardt2019-06-151-4/+4
| | | | | | | | | | 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).
* posix: remove implicit include of "fnmatch.h"Patrick Steinhardt2019-06-151-1/+1
| | | | | | | | 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.
* refspec: fix transforming nested starsPatrick Steinhardt2019-04-261-12/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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".
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-15/+15
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* references: use new names in internal usageethomson/git_refEdward Thomson2019-01-171-2/+3
| | | | Update internal usage to use the `git_reference` names for constants.
* treewide: remove use of C++ style commentsPatrick Steinhardt2018-07-131-1/+1
| | | | | | | | | 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.
* Merge pull request #4699 from nelhage/fetch-null-dstPatrick Steinhardt2018-07-061-1/+1
|\ | | | | git_refspec_transform: Handle NULL dst
| * git_refspec_transform: Handle NULL dstNelson Elhage2018-06-251-1/+1
| |
* | refspec: rename `git_refspec__free` to `git_refspec__dispose`Patrick Steinhardt2018-06-291-3/+3
| | | | | | | | | | | | | | | | | | 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.
* | refspec: add public parsing apicynecx2018-06-221-0/+25
|/ | | | | | | | | | | | | | | | | | | | Fix typo Fix some type issues More fixes Address requested changes Add test Fix naming Fix condition and tests Address requested changes Fix typo
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-1/+1
|
* refspec: check for valid parameters in git_refspec__dwim_oneEtienne Samson2018-04-201-1/+4
| | | | CID:1383993, "In git_refspec__dwim_one: All paths that lead to this null pointer comparison already dereference the pointer earlier (CWE-476)"
* Make sure to always include "common.h" firstPatrick Steinhardt2017-07-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* refspec: do not set empty rhs for fetch refspecsPatrick Steinhardt2016-08-041-2/+4
| | | | | | | | | | | | | | | | | | | | 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.
* refspec: check buffer with GITERR_CHECK_ALLOC_BUFPatrick Steinhardt2016-02-231-4/+4
|
* fix memory leak in refspec.c on errors.Jeff Hostetler2015-06-301-0/+3
|
* refspec: make sure matching refspecs have src, dst and input stringsCarlos Martín Nieto2015-05-221-0/+6
| | | | | | | | 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.
* refspec: set err message on invalid refspecAdrien Thebo2015-03-101-0/+3
| | | | | | | 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.
* push: use the common refspec parsercmn/push-refspec-refactorCarlos Martín Nieto2014-11-091-0/+6
| | | | | | | | | | | 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.
* Check that the refspec matches before modifying the out bufferJacques Germishuys2014-08-211-6/+6
|
* Check if the refspec matches before transformingJacques Germishuys2014-08-171-2/+14
|
* refspec: support asterisks in the middle of a patternCarlos Martín Nieto2014-07-041-18/+32
| | | | | | | | | | 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.
* refspec: short-circuit non-pattern refspecs on transformCarlos Martín Nieto2014-07-041-0/+10
| | | | | | 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.
* refspec: move to git_buf for outputting stringsCarlos Martín Nieto2014-01-271-50/+4
|
* remote: store dwimed refspecs separatelyCarlos Martín Nieto2013-11-011-0/+68
| | | | | This allows us to add e.g. "HEAD" as a refspec when none are given without overwriting the user's data.
* Make refspec_transform paranoid about argumentsRussell Belfer2013-07-011-14/+20
|
* refspec: add direction accessorCarlos Martín Nieto2013-04-301-0/+7
|
* Parse shorthand refspecs as validCarlos Martín Nieto2013-04-281-1/+1
| | | | | Relax the ONELEVEL ref naming rules so the refspec parsing code can ask for 'master' to be considered valid.
* refspec: unify the string and parsed dataCarlos Martín Nieto2013-04-201-0/+9
| | | | | | | | 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.
* remote: handle multiple refspecsCarlos Martín Nieto2013-04-201-0/+1
| | | | | | | | | | | | | 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.
* Teach refspec to transform destination reference to source referenceJameson Miller2013-02-111-7/+17
|
* Teach remote branch to return its remoteJameson Miller2013-02-111-0/+8
|
* refspec: prevent git_refspec__free() from segfaultingnulltoken2013-01-111-0/+3
| | | | Fix libgit2/libgit2sharp#247
* update copyrightsEdward Thomson2013-01-081-1/+1
|
* create FETCH_HEAD specially instead of as a ref fileEdward Thomson2012-11-111-0/+7
|
* refspec: introduce git_refspec__serialize()nulltoken2012-10-251-0/+11
|
* refspec: introduce git_refspec_transform_l()nulltoken2012-10-081-4/+14
|
* refspec: add git_refspec__free, remove git_refspec_parseCarlos Martín Nieto2012-09-301-28/+3
| | | | | | | 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.
* refspec: introduce git_refspec__parse()nulltoken2012-09-251-0/+113
|
* refspec: expose the force update specifier through git_refspec_force() accessornulltoken2012-05-301-0/+7
|
* errors: Rename error codesbreaking-changesVicent Martí2012-05-181-2/+2
|
* errors: Rename the generic return codesVicent Martí2012-05-181-2/+2
|
* Remove old and unused error codesVicent Martí2012-05-021-2/+6
|
* Merge remote-tracking branch 'carlosmn/remaining-errors' into new-error-handlingVicent Martí2012-05-011-18/+19
|\ | | | | | | | | Conflicts: src/refspec.c
View Lorry Controller Status