Hi all, Bruno Haible via Gnulib discussion list <[email protected]> writes:
> Patrick GARCIA wrote: >> I did not manage to use "vc-dwim" properly. > > vc-dwim is used to create a ChangeLog entry. When you provide a patch > with a reasonable git commit message, we can easily turn that into > a ChangeLog entry. Therefore, no real need to use 'vc-dwim'. Patrick, you are probably looking for vc-chlog if you would like to generate change logs. Here is it's output after making some trivial changes to a few files in Gnulib: $ vc-chlog 2025-11-01 Collin Funk <[email protected]> * Makefile (sc_prohibit_sc_omitted_at): * lib/xmalloc.c (xmalloc, xireallocarray): Typically it works well, but you may need to do some manual adjustment. Sometimes macro or function names are incorrect, e.g. the preceding function will be used. Here is my configuration so I do not need to give the program arguments: $ cat ~/.vc-chlogrc # ~/.vc-chlogrc --address "[email protected]" --user-name "Collin Funk" # Local Variables: # mode: shell-script # End: Alternatively, if you use Emacs you can use the 'add-change-log-entry' and 'add-change-log-entry-other-window' functions. > When you propose a patch, you should provide an explanation regarding > the situation where it provides an improvement. > > - Which OS? I guess GNU/Linux, but you should better state that > explicitly. > - What are the "How to reproduce" instructions? > > Your git commit message gives only partial answers: > > - What do you mean by "logical" file name resolution? > - "NOLINKS" flag - what do you mean by that? > - "current-directory is a sybolic-link" - what do you mean by that? > When a process enters a directory via chdir(), is follows symbolic > links. Therefore the current directory is _never_ a symbolic link, > it is _always_ a real directory. Agreed. >> PS : I will, then, propose a shell unit-test to the coreutils team. > > Ideally, since Gnulib is a C functions library, the unit test should > be a small self-contained C program. That test program lives in > gnulib/tests/. Yep, since Gnulib started out as files imported from Coreutils it might be unclear depending on the module that you look at. Some modules are missing tests in Gnulib (*), probably because they are not used much outside of Coreutils or are used by other modules with tests. See my recent addition of tests for savewd for an example [1]. (*) It would be a welcome change to add tests for those modules, though. You can use a shell script with the following to find some: for module in `gnulib-tool --list`; do test_module=`gnulib-tool --extract-tests-module "$module"` if test -z "$test_module"; then echo "$module" fi done Collin [1] https://lists.gnu.org/archive/html/bug-gnulib/2025-10/msg00048.html
