Re: FYI: 3 small patches

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> According to Jim Meyering on 4/22/2008 8:28 AM:
> | Without a guard like this, it is far too easy to apply a patch
> | prepared against a preceding release, and not notice that a NEWS
> | entry is inserted into the wrong block.
> | * maint.mk (sc_immutable_NEWS): New rule.
> | (update-NEWS-hash): New rule to update the hard-coded hash.
> |
> | +
> | +# Ensure that we don't accidentally insert an entry into an old NEWS block.
> | +old_NEWS_hash = c58d611d93d218181ed77f81ff2395ff  -
> | +sc_immutable_NEWS:
> | +   @if test -f $(srcdir)/NEWS; then                                \
> | +     test "$(NEWS_hash)" = '$(old_NEWS_hash)' && : ||              \
> | +       { echo '$(ME): you have modified old NEWS' 1>&2; exit 1; }; \
> | +   fi
> | +
> | +# Update the hash stored above.  Do this after each release.
> | +update-NEWS-hash: NEWS
> | +   perl -pi -e 's/^(old_NEWS_hash = ).*/$${1}'"$(NEWS_hash)/" $(ME)
>
> Nice rule.  However, two concerns here.  First, how do you intend to share
> maint.mk with other projects, when the NEWS hash to coreutils is now
> hardcoded in here?  Shouldn't the hash be stored in cfg.mk instead?

You caught me ;-).  Actually I thought of that initially, but then
forgot when implementing it.  I'll move it right away.  Thanks.

> Second, what happens if a typo correction is made in the old NEWS?  I
> guess that means manually updating the hash to account for the intentional
> changes (or maybe running 'make update-NEWS-hash' after ensuring that all
> I changed was a typo fix).

Exactly, but don't run it manually.
I'll add a comment that it's ok to run it for corrections, too.

BTW, I do want to update NEWS as you suggested re ls --colors,
but haven't done it yet.  If you already know what it should
say, I'd love a patch that would save me the time of digging
for it all over again.