Re: [PATCH/RFC] fsck: complain when .gitignore and .gitattributes are symlinks
- From
Ramsay Jones <ramsay@ramsayjones.plus.com>
- Date
- Jan 22, 2019, 18:19 UTC
- Message-ID
- <8ea563e7-8b3f-dc38-3aec-02253690b6b7@ramsayjones.plus.com>
- In-Reply-To
- <20190122072359.GE28555@sigill.intra.peff.net>
On 22/01/2019 07:23, Jeff King wrote:
Show 18 quoted lines
> On Fri, Jan 18, 2019 at 01:41:08AM +0000, Ramsay Jones wrote:
>
>> I don't do this "from time to time", but *every* build on all
>> platforms! :-D
>>
>> As I have mentioned before, I run the script on 'master', 'next'
>> and 'pu', but I don't look at the results for 'master', I simply
>> look at the diffs master->next and next->pu.
>
> Ah, ok, that explains it, then. As you noted, these made it straight to
> master because of the security embargo.
>
> Thanks for satisfying my curiosity (and for running your script!).
>
> I do wonder if you might be better off comparing master@{1} to master to
> see if anything new appears (since I assume the whole point is ignoring
> historical false positives, and just looking at patches under active
> development).Hmm, well it's not so much 'historical false positives' as 'oh dear, they managed to get through' (along with a promise to myself to get around to tidying up the symbols in master - yet again!). ;-)
I try to make people aware of the issues, when they appear in 'pu', so that we have a chance not to make things worse. However, it is never as simple as 'this symbol is not used/local to this file, please fix' (despite what it looks like, I don't like to annoy contributors with those emails :-D ). Many recent large changes have been split into several series with earlier series introducing symbols which 'will be used later'. Sometimes later never comes. ;-)
Recently, Brian's 'bc/sha-256' branch merged into 'next', so now:
$ diff sc nsc 37a38,39 > hex.o - hash_to_hex > hex.o - hash_to_hex_algop_r 74a77,78 > sha1-file.o - hash_algo_by_id > sha1-file.o - hash_algo_by_name $
Brian has already indicated [1] that future patches will add uses for these symbols.
[1] https://public-inbox.org/git/20181114021118.GN890086@genre.crustytoothpaste.net/
[Just to be clear, my script only notes symbols that are not referenced outside of the object file which contains its definition - so that includes file-local and unused symbols].
There are currently 90 symbols in the 'sc' file, some of which should be added to the outdated 'skip list'. Just FYI, the file which has the most hits is:
$ cut -f1 sc | sort | uniq -c | sort -rn
26 config.o
6 sha1dc/sha1.o
6 refs.o
6 json-writer.o
3 utf8.o
3 sha1-file.o
3 revision.o
3 refs/ref-cache.o
2 vcs-svn/fast_export.o
2 refs/packed-backend.o
2 path.o
2 parse-options.o
2 graph.o
2 attr.o
1 worktree.o
1 trace.o
1 tmp-objdir.o
1 tempfile.o
1 strbuf.o
1 serve.o
1 sequencer.o
1 refspec.o
1 refs/iterator.o
1 read-cache.o
1 pkt-line.o
1 oidmap.o
1 line-log.o
1 ident.o
1 hex.o
1 gettext.o
1 fuzz-pack-idx.o
1 fuzz-pack-headers.o
1 editor.o
1 credential.o
1 convert.o
1 builtin/pack-objects.o
$ ... and the symbols in that file:
$ grep config.o sc config.o - git_config_copy_section_in_file config.o - git_config_from_file_with_options config.o - git_config_from_parameters config.o - git_config_get_bool_or_int config.o - git_config_get_maybe_bool config.o - git_config_get_pathname config.o - git_config_include config.o - git_config_key_is_valid config.o - git_configset_get_bool config.o - git_configset_get_bool_or_int config.o - git_configset_get_int config.o - git_configset_get_maybe_bool config.o - git_configset_get_pathname config.o - git_configset_get_string config.o - git_configset_get_string_const config.o - git_configset_get_ulong config.o - git_config_set_multivar_in_file config.o - git_config_system config.o - git_die_config_linenr config.o - repo_config config.o - repo_config_get_bool_or_int config.o - repo_config_get_int config.o - repo_config_get_maybe_bool config.o - repo_config_get_pathname config.o - repo_config_get_ulong config.o - repo_config_get_value $
ATB, Ramsay Jones