On Mon, Dec 19, 2022 at 10:46 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Fri, Dec 16 2022, Karthik Nayak wrote: > > > v1: https://lore.kernel.org/git/20221206103736.53909-1-karthik.188@xxxxxxxxx/ > > v2: https://lore.kernel.org/git/CAOLa=ZSsFGBw3ta1jWN8cmUch2ca=zTEjp1xMA6Linafx9W53g@xxxxxxxxxxxxxx/T/#t > > > > Given a pathname, git-check-attr(1) will list the attributes which apply to that > > pathname by reading all relevant gitattributes files. Currently there is no way > > to specify a revision to read the gitattributes from. > > > > This is specifically useful in bare repositories wherein the gitattributes are > > only present in the git working tree but not available directly on the > > filesystem. > > > > This series aims to add a new flag `-r|--revisions` to git-check-attr(1) which > > allows us to read gitattributes from the specified revision. > > > > Changes since version 2: > > - Changes to the commit message [1/2] to use more specific terms and to > > be more descriptive. > > - Moved the flag's position in the documentation to be before the unbound > > list of non-options. > > Aside from the UX concerns with this series, this segfaults with it, but > not on "master": > > ./git check-attr diff git-send-email.perl foo.perl git-send-email.perl > AddressSanitizer:DEADLYSIGNAL > ================================================================= > ==1828755==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x0000008ee4a8 bp 0x7fffe4cef820 sp 0x7fffe4cef800 T0) > ==1828755==The signal is caused by a READ memory access. > ==1828755==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used. > #0 0x8ee4a8 in hasheq_algop hash.h:236 > #1 0x8ee632 in oideq hash.h:253 > #2 0x8ee657 in is_null_oid hash.h:258 > #3 0x8f79e2 in do_oid_object_info_extended object-file.c:1550 > #4 0x8f8206 in oid_object_info_extended object-file.c:1640 > #5 0x8f860c in read_object object-file.c:1672 > #6 0x8f8a8a in read_object_file_extended object-file.c:1715 > #7 0x8f01ef in repo_read_object_file object-store.h:253 > #8 0x8f8e37 in read_object_with_reference object-file.c:1756 > #9 0xafb411 in get_tree_entry tree-walk.c:612 > #10 0x6d1975 in read_attr_from_blob attr.c:776 > #11 0x6d1b80 in read_attr attr.c:826 > #12 0x6d1f35 in bootstrap_attr_stack attr.c:912 > #13 0x6d2173 in prepare_attr_stack attr.c:948 > #14 0x6d3285 in collect_some_attrs attr.c:1143 > #15 0x6d33e1 in git_check_attr attr.c:1157 > #16 0x453581 in check_attr builtin/check-attr.c:72 > #17 0x453f1f in cmd_check_attr builtin/check-attr.c:190 > #18 0x40b63d in run_builtin git.c:466 > #19 0x40bf7f in handle_builtin git.c:721 > #20 0x40c686 in run_argv git.c:788 > #21 0x40d42f in cmd_main git.c:926 > #22 0x6885b5 in main common-main.c:57 > #23 0x7f96725a8189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > #24 0x7f96725a8244 in __libc_start_main_impl ../csu/libc-start.c:381 > #25 0x407230 in _start (git+0x407230) > > AddressSanitizer can not provide additional info. > SUMMARY: AddressSanitizer: SEGV hash.h:236 in hasheq_algop > ==1828755==ABORTING > Aborted > > If the tests are still passing for you (I didn't check) then we probably > have a bad test blind spot with kthat we should start by addressing > before adding the new feature. This seems to be what Junio mentioned here: https://lore.kernel.org/git/xmqqcz8ikgxs.fsf@gitster.g/ Should be fixed in v4! -- - Karthik
