bug#6557: du sometimes miscounts directories, and files whose link count equals 1

[Jim Meyering]

Paul Eggert wrote:
> On 07/03/10 01:36, Jim Meyering wrote:
>
>> Here's the adjusted patch, for review.
>
> Yes, thanks, that looks good and it works for me.

I've pushed that du fix.

>> Also, I added a log line for the tests/du/files0-from change.
>> (BTW, the following is the output from "git format-patch --stdout -1".
>> It's easy to apply that by saving it in a FILE, then running "git am FILE")
>
> Yes, and here's a proposed change to README-hacking to try to record
> this advice, along with some other good advice you've given me recently:

Thanks!

> Subject: [PATCH] Add advice about ChangeLogs and synchronizing submodules.

I like to put a "doc: " at the beginning of such summary lines
and to omit the trailing ".":

  doc: add advice about ChangeLogs and synchronizing submodules

> * README-hacking: Adjust accordingly.
> ---
>  README-hacking |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/README-hacking b/README-hacking
> index fecbf9e..02cb277 100644
> --- a/README-hacking
> +++ b/README-hacking
> @@ -39,6 +39,12 @@ which are extracted from other source packages:
>
>          $ ./bootstrap
>
> +To use the most-recent gnulib (as opposed to the gnulib version that
> +the package last synchronized to), do this next:
> +
> +        $ git submodule foreach git pull origin master
> +        $ git commit -a -m 'build: update gnulib submodule to latest'

In general, I try to ensure that each gnulib-updating change
remains in a commit all by itself[*], partly because
they are relatively likely to conflict -- esp. if I do the
update on a branch, later update to a different version
on the trunk and try to rebase.  If it's a commit by itself
it's trivial to avoid trouble: just remove the commit before rebasing
the branch.

So maybe this, instead?

       $ git commit -m 'build: update gnulib submodule to latest' gnulib

[*] However, when a gnulib change induces a matching change
in coreutils, the gnulib-updating part obviously belongs
with the coreutils-changing deltas.

>  And there you are!  Just
>
>          $ ./configure --quiet #[--enable-gcc-warnings] [*]
> @@ -60,6 +66,29 @@ to use recent system headers.  If you configure with this 
> option,
>  and spot a problem, please be sure to send the report to the bug
>  reporting address of this package, and not to that of gnulib, even
>  if the problem seems to originate in a gnulib-provided file.
> +
> +* Submitting patches
> +
> +If you develop a fix or a new feature, please send it to the
> +appropriate bug-reporting address as reported by the --help option of
> +each program.  One way to do this is to use vc-dwim
> +<http://www.gnu.org/software/vc-dwim/>), as follows.
> +
> +  Run the command "vc-dwim --help", copy its definition of the
> +  "git-changelog-symlink-init" function into your shell, and then run
> +  this function at the top-level directory of the package.

This (above and below) is precisely the process I use.
Thanks for documenting it.  It may sound a little tortuous,
but has some hidden benefits.

> +  Edit the ChangeLog file that this command creates, creating a
> +  properly-formatted entry according to the GNU coding standards
> +  <http://www.gnu.org/prep/standards/html_node/Change-Logs.html>.
> +
> +  Run the command "vc-dwim" and make sure its output looks good.
> +
> +  Run "vc-dwim --commit".
> +
> +  Run the command "git format-patch --stdout -1", and email its output
> +  in, using the the output's subject line.
---------------^^^ ^^^

"make syntax-check" spotted the doubled "the".

You're welcome to push the result.