git/object-name.c, branch v2.37.2

object-name: diagnose trees in index properly

2022-04-26T20:56:39Z

When running 'git show :' where '' is a directory, then there is a subtle difference between a full checkout and a sparse checkout. The error message from diagnose_invalid_index_path() reports whether the path is on disk or not. The full checkout will have the directory on disk, but the path will not be in the index. The sparse checkout could have the directory not exist, specifically when that directory is outside of the sparse-checkout cone. In the case of a sparse index, we have yet another state: the path can be a sparse directory in the index. In this case, the error message from diagnose_invalid_index_path() would erroneously say "path '' is in the index, but not at stage 0", which is false. Add special casing around sparse directory entries so we get to the correct error message. This requires two checks in order to get parity with the normal sparse-checkout case. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

object-name: reject trees found in the index

2022-04-26T20:56:38Z

The get_oid_with_context_1() method is used when parsing revision arguments. One particular case is to take a ":" string and search the index for the given path. In the case of a sparse index, this might find a sparse directory entry, in which case the contained object is a tree. In the case of a full index, this search within the index would fail. In order to maintain identical return state as in a full index, inspect the discovered cache entry to see if it is a sparse directory and reject it. This requires being careful around the only_to_die option to be sure we die only at the correct time. This changes the behavior of 'git show :', but does not bring it entirely into alignment with a full index case. It specifically hits the wrong error message within diagnose_invalid_index_path(). That error message will be corrected in a future change. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'ab/date-mode-release'

2022-02-25T23:47:36Z

Plug (some) memory leaks around parse_date_format(). * ab/date-mode-release: date API: add and use a date_mode_release() date API: add basic API docs date API: provide and use a DATE_MODE_INIT date API: create a date.h, split from cache.h cache.h: remove always unused show_date_human() declaration

Merge branch 'ab/ambiguous-object-name'

2022-02-25T23:47:33Z

Error output given in response to an ambiguous object name has been improved. * ab/ambiguous-object-name: object-name: re-use "struct strbuf" in show_ambiguous_object() object-name: iterate ambiguous objects before showing header object-name: show date for ambiguous tag objects object-name: make ambiguous object output translatable object-name: explicitly handle bad tags in show_ambiguous_object() object-name: explicitly handle OBJ_BAD in show_ambiguous_object() object-name tests: add tests for ambiguous object blind spots

date API: create a date.h, split from cache.h

2022-02-16T17:40:00Z

Move the declaration of the date.c functions from cache.h, and adjust the relevant users to include the new date.h header. The show_ident_date() function belonged in pretty.h (it's defined in pretty.c), its two users outside of pretty.c didn't strictly need to include pretty.h, as they get it indirectly, but let's add it to them anyway. Similarly, the change to "builtin/{fast-import,show-branch,tag}.c" isn't needed as far as the compiler is concerned, but since they all use the "DATE_MODE()" macro we now define in date.h, let's have them include it. We could simply include this new header in "cache.h", but as this change shows these functions weren't common enough to warrant including in it in the first place. By moving them out of cache.h changes to this API will no longer cause a (mostly) full re-build of the project when "make" is run. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

object-name: re-use "struct strbuf" in show_ambiguous_object()

2022-01-27T20:09:34Z

Reduce the allocations done by show_ambiguous_object() by moving the "desc" strbuf into the "struct ambiguous_output" introduced in the preceding commit. This doesn't matter for optimization purposes, but since we're accumulating a "struct strbuf advice" anyway let's follow that pattern and add a "struct strbuf sb", we can then strbuf_reset() it rather than calling strbuf_release() for each call to show_ambiguous_object(). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

object-name: iterate ambiguous objects before showing header

2022-01-27T20:09:34Z

Change the "The candidates are" header that's shown for ambiguous objects to be shown after we've iterated over all of the objects. If we get any errors while doing so we don't want to split up the the header and the list as a result. The two will now be printed together, as shown in the updated testcase. As we're accumulating the lines into as "struct strbuf" before emitting them we need to add a trailing newline to the call in show_ambiguous_object(). This and the change from "The candidates are:" to "The candidates are:\n%s" helps to give translators more context. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

object-name: show date for ambiguous tag objects

2022-01-27T20:09:33Z

Make the ambiguous tag object output nicer in the case of tag objects such as ebf3c04b262 (Git 2.32, 2021-06-06) by including the date in the "tagger" header. I.e.: $ git rev-parse b7e68 error: short object ID b7e68 is ambiguous hint: The candidates are: hint: b7e68c41d92 tag 2021-06-06 - v2.32.0 hint: b7e68ae18e0 commit 2019-12-23 - bisect: use the standard 'if (!var)' way to check for 0 hint: b7e68f6b413 tree hint: b7e68490b97 blob b7e68 [...] Before this we'd emit a "tag" line without a date, e.g.: hint: b7e68c41d92 tag v2.32.0 Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

object-name: make ambiguous object output translatable

2022-01-27T20:09:33Z

Change the output of show_ambiguous_object() added in [1] and last tweaked in [2] and the preceding commit to be more friendly to translators. By being able to customize the "%s\n" format we're even ready for RTL languages, who'd presumably like to change that to "%s\n". In the case of the existing "tag [tag could not be parsed]" output we'll now instead emit "[bad tag, could not parse it]". This is consistent with the "[bad object]" output. Rephrasing the message like this is possible because we're not unconditionally adding the type_name() at the beginning. 1. 1ffa26c461 (get_short_sha1: list ambiguous objects on error, 2016-09-26) 2. 5cc044e0257 (get_short_oid: sort ambiguous objects by type, then SHA-1, 2018-05-10) Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Josh Steadmon Signed-off-by: Junio C Hamano

object-name: explicitly handle bad tags in show_ambiguous_object()

2022-01-27T20:09:33Z

Follow-up the handling of OBJ_BAD in the preceding commit and explicitly handle those cases where parse_tag() fails, or we don't end up with a non-NULL pointer in in tag->tag. If we run into such a tag we'd previously be silent about it. We really should also be handling these batter in parse_tag_buffer() by being more eager to emit an error(), instead of silently aborting with "return -1;". One example of such a tag is the one that's tested for in "t3800-mktag.sh", where the code takes the "size < the_hash_algo->hexsz + 24" branch. But in lieu of earlier missing "error" output let's show the user something to indicate why we're not showing a tag message in these cases, now instead of showing: hint: deadbeef tag We'll instead display: hint: deadbeef tag [tag could not be parsed] Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano