summaryrefslogtreecommitdiff
path: root/refspec.c
AgeCommit message (Collapse)AuthorFilesLines
2020-12-14Merge branch 'fc/atmark-in-refspec'Libravatar Junio C Hamano1-1/+4
"@" sometimes worked (e.g. "git push origin @:there") as a part of a refspec element, but "git push origin @" did not work, which has been corrected. * fc/atmark-in-refspec: refspec: make @ a synonym of HEAD tests: push: trivial cleanup tests: push: improve cleanup of HEAD tests
2020-12-01refspec: trivial cleanupLibravatar Felipe Contreras1-9/+10
We can remove one level of indentation and make the code clearer. No functional changes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30refspec: make @ a synonym of HEADLibravatar Felipe Contreras1-1/+4
Since commit 9ba89f484e git learned how to push to a remote branch using the source @, for example: git push origin @:master However, if the right-hand side is missing, the push fails: git push origin @ It is obvious what is the desired behavior, and allowing the push makes things more consistent. Additionally, @:master now has the same semantics as HEAD:master. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27Merge branch 'sb/clone-origin'Libravatar Junio C Hamano1-0/+10
"git clone" learned clone.defaultremotename configuration variable to customize what nickname to use to call the remote the repository was cloned from. * sb/clone-origin: clone: allow configurable default for `-o`/`--origin` clone: read new remote name from remote_name instead of option_origin clone: validate --origin option before use refs: consolidate remote name validation remote: add tests for add and rename with invalid names clone: use more conventional config/option layering clone: add tests for --template and some disallowed option pairs
2020-10-05Merge branch 'jk/refspecs-negative'Libravatar Junio C Hamano1-2/+32
"git fetch" and "git push" support negative refspecs. * jk/refspecs-negative: refspec: add support for negative refspecs
2020-09-30refs: consolidate remote name validationLibravatar Sean Barag1-0/+10
In preparation for a future patch, extract from remote.c a function that validates possible remote names so that its rules can be used consistently in other places. Helped-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Sean Barag <sean@barag.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30refspec: add support for negative refspecsLibravatar Jacob Keller1-2/+32
Both fetch and push support pattern refspecs which allow fetching or pushing references that match a specific pattern. Because these patterns are globs, they have somewhat limited ability to express more complex situations. For example, suppose you wish to fetch all branches from a remote except for a specific one. To allow this, you must setup a set of refspecs which match only the branches you want. Because refspecs are either explicit name matches, or simple globs, many patterns cannot be expressed. Add support for a new type of refspec, referred to as "negative" refspecs. These are prefixed with a '^' and mean "exclude any ref matching this refspec". They can only have one "side" which always refers to the source. During a fetch, this refers to the name of the ref on the remote. During a push, this refers to the name of the ref on the local side. With negative refspecs, users can express more complex patterns. For example: git fetch origin refs/heads/*:refs/remotes/origin/* ^refs/heads/dontwant will fetch all branches on origin into remotes/origin, but will exclude fetching the branch named dontwant. Refspecs today are commutative, meaning that order doesn't expressly matter. Rather than forcing an implied order, negative refspecs will always be applied last. That is, in order to match, a ref must match at least one positive refspec, and match none of the negative refspecs. This is similar to how negative pathspecs work. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-06refspec: add and use refspec_appendf()Libravatar René Scharfe1-2/+16
Add a function for building a refspec using printf-style formatting. It frees callers from managing their own buffer. Use it throughout the tree to shorten and simplify its callers. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28strvec: fix indentation in renamed callsLibravatar Jeff King1-2/+2
Code which split an argv_array call across multiple lines, like: argv_array_pushl(&args, "one argument", "another argument", "and more", NULL); was recently mechanically renamed to use strvec, which results in mis-matched indentation like: strvec_pushl(&args, "one argument", "another argument", "and more", NULL); Let's fix these up to align the arguments with the opening paren. I did this manually by sifting through the results of: git jump grep 'strvec_.*,$' and liberally applying my editor's auto-format. Most of the changes are of the form shown above, though I also normalized a few that had originally used a single-tab indentation (rather than our usual style of aligning with the open paren). I also rewrapped a couple of obvious cases (e.g., where previously too-long lines became short enough to fit on one), but I wasn't aggressive about it. In cases broken to three or more lines, the grouping of arguments is sometimes meaningful, and it wasn't worth my time or reviewer time to ponder each case individually. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28strvec: convert remaining callers away from argv_array nameLibravatar Jeff King1-2/+2
We eventually want to drop the argv_array name and just use strvec consistently. There's no particular reason we have to do it all at once, or care about interactions between converted and unconverted bits. Because of our preprocessor compat layer, the names are interchangeable to the compiler (so even a definition and declaration using different names is OK). This patch converts all of the remaining files, as the resulting diff is reasonably sized. The conversion was done purely mechanically with: git ls-files '*.c' '*.h' | xargs perl -i -pe ' s/ARGV_ARRAY/STRVEC/g; s/argv_array/strvec/g; ' We'll deal with any indentation/style fallouts separately. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28strvec: rename files from argv-array to strvecLibravatar Jeff King1-1/+1
This requires updating #include lines across the code-base, but that's all fairly mechanical, and was done with: git ls-files '*.c' '*.h' | xargs perl -i -pe 's/argv-array.h/strvec.h/' Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-01refspec: make hash size independentLibravatar brian m. carlson1-1/+1
Switch a use of GIT_SHA1_HEXSZ to use the_hash_algo. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23refspec.c: mark more strings for translationLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23Update messages in preparation for i18nLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Many messages will be marked for translation in the following commits. This commit updates some of them to be more consistent and reduce diff noise in those commits. Changes are - keep the first letter of die(), error() and warning() in lowercase - no full stop in die(), error() or warning() if it's single sentence messages - indentation - some messages are turned to BUG(), or prefixed with "BUG:" and will not be marked for i18n - some messages are improved to give more information - some messages are broken down by sentence to be i18n friendly (on the same token, combine multiple warning() into one big string) - the trailing \n is converted to printf_ln if possible, or deleted if not redundant - errno_errno() is used instead of explicit strerror() Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-28Merge branch 'ab/refspec-init-fix'Libravatar Junio C Hamano1-4/+9
Make refspec parsing codepath more robust. * ab/refspec-init-fix: refspec: initalize `refspec_item` in `valid_fetch_refspec()` refspec: add back a refspec_item_init() function refspec: s/refspec_item_init/&_or_die/g
2018-06-11refspec: initalize `refspec_item` in `valid_fetch_refspec()`Libravatar Martin Ågren1-1/+1
We allocate a `struct refspec_item` on the stack without initializing it. In particular, its `dst` and `src` members will contain some random data from the stack. When we later call `refspec_item_clear()`, it will call `free()` on those pointers. So if the call to `parse_refspec()` did not assign to them, we will be freeing some random "pointers". This is undefined behavior. To the best of my understanding, this cannot currently be triggered by user-provided data. And for what it's worth, the test-suite does not trigger this with SANITIZE=address. It can be provoked by calling `valid_fetch_refspec(":*")`. Zero the struct, as is done in other users of `struct refspec_item` by using the refspec_item_init() initialization function. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11refspec: add back a refspec_item_init() functionLibravatar Ævar Arnfjörð Bjarmason1-3/+7
Re-add the non-fatal version of refspec_item_init_or_die() renamed away in an earlier change to get a more minimal diff. This should be used by callers that have their own error handling. This new function could be marked "static" since nothing outside of refspec.c uses it, but expecting future use of it, let's make it available to other users. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11refspec: s/refspec_item_init/&_or_die/gLibravatar Ævar Arnfjörð Bjarmason1-2/+3
Rename the refspec_item_init() function introduced in 6d4c057859 ("refspec: introduce struct refspec", 2018-05-16) to refspec_item_init_or_die(). This follows the convention of other *_or_die() functions, and is done in preparation for making it a wrapper for a non-fatal variant. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-04Merge branch 'bw/refspec-api'Libravatar Junio C Hamano1-0/+2
Hotfix. * bw/refspec-api: refspec-api: avoid uninitialized field in refspec item
2018-06-01fetch: do not pass ref-prefixes for fetch by exact SHA1Libravatar Jonathan Nieder1-0/+2
When v2.18.0-rc0~10^2~1 (refspec: consolidate ref-prefix generation logic, 2018-05-16) factored out the ref-prefix generation code for reuse, it left out the 'if (!item->exact_sha1)' test in the original ref-prefix generation code. As a result, fetches by SHA-1 generate ref-prefixes as though the SHA-1 being fetched were an abbreviated ref name: $ GIT_TRACE_PACKET=1 bin-wrappers/git -c protocol.version=2 \ fetch origin 12039e008f9a4e3394f3f94f8ea897785cb09448 [...] packet: fetch> ref-prefix 12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/tags/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/heads/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448/HEAD packet: fetch> 0000 If there is another ref name on the command line or the object being fetched is already available locally, then that's mostly harmless. But otherwise, we error out with fatal: no matching remote head since the server did not send any refs we are interested in. Filter out the exact_sha1 refspecs to avoid this. This patch adds a test to check this behavior that notices another behavior difference between protocol v0 and v2 in the process. Add a NEEDSWORK comment to clear it up. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01refspec-api: avoid uninitialized field in refspec itemLibravatar Junio C Hamano1-0/+2
When parse_refspec() function was created at 3eec3700 ("refspec: factor out parsing a single refspec", 2018-05-16) to take a caller supplied piece of memory to fill parsed refspec_item, it forgot that a refspec without colon must set item->dst to NULL to let the users of refspec know that the result of the fetch does not get stored in an ref on our side. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18refspec: consolidate ref-prefix generation logicLibravatar Brandon Williams1-0/+29
When using protocol v2 a client constructs a list of ref-prefixes which are sent across the wire so that the server can do server-side filtering of the ref-advertisement. The logic that does this exists for both fetch and push (even though no push support for v2 currently exists yet) and is roughly the same so lets consolidate this logic and make it general enough that it can be used for both the push and fetch cases. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18refspec: remove the deprecated functionsLibravatar Brandon Williams1-49/+0
Now that there are no callers of 'parse_push_refspec()', 'parse_fetch_refspec()', and 'free_refspec()', remove these functions. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18refspec: convert valid_fetch_refspec to use parse_refspecLibravatar Brandon Williams1-9/+8
Convert 'valid_fetch_refspec()' to use the new 'parse_refspec()' function to only parse a single refspec and eliminate an allocation. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18refspec: introduce struct refspecLibravatar Brandon Williams1-0/+64
Introduce 'struct refspec', an abstraction around a collection of 'struct refspec_item's much like how 'struct pathspec' holds a collection of 'struct pathspec_item's. A refspec struct also contains an array of the original refspec strings which will be used to facilitate the migration to using this new abstraction throughout the code base. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18refspec: factor out parsing a single refspecLibravatar Brandon Williams1-91/+104
Factor out the logic which parses a single refspec into its own function. This makes it easier to reuse this logic in a future patch. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18refspec: rename struct refspec to struct refspec_itemLibravatar Brandon Williams1-8/+8
In preparation for introducing an abstraction around a collection of refspecs (much like how a 'struct pathspec' is a collection of 'struct pathspec_item's) rename the existing 'struct refspec' to 'struct refspec_item'. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-18refspec: move refspec parsing logic into its own fileLibravatar Brandon Williams1-0/+167
In preparation for performing a refactor on refspec related code, move the refspec parsing logic into its own file. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>