user/sven/git.git/refspec.c, branch v2.26.0-rc2

refspec: make hash size independent

2019-04-01T02:57:39Z

Switch a use of GIT_SHA1_HEXSZ to use the_hash_algo. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

refspec.c: mark more strings for translation

2018-07-23T18:19:10Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Update messages in preparation for i18n

2018-07-23T18:19:09Z

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 Signed-off-by: Junio C Hamano

Merge branch 'ab/refspec-init-fix'

2018-06-28T19:53:29Z

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

refspec: initalize `refspec_item` in `valid_fetch_refspec()`

2018-06-11T17:11:32Z

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 Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

refspec: add back a refspec_item_init() function

2018-06-11T17:11:31Z

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 Signed-off-by: Junio C Hamano

refspec: s/refspec_item_init/&_or_die/g

2018-06-11T17:11:29Z

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 Signed-off-by: Junio C Hamano

Merge branch 'bw/refspec-api'

2018-06-04T12:39:50Z

Hotfix. * bw/refspec-api: refspec-api: avoid uninitialized field in refspec item

fetch: do not pass ref-prefixes for fetch by exact SHA1

2018-06-01T06:15:22Z

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 Signed-off-by: Junio C Hamano

refspec-api: avoid uninitialized field in refspec item

2018-06-01T02:46:07Z

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