[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI: 3 small patches
From: |
Jim Meyering |
Subject: |
Re: FYI: 3 small patches |
Date: |
Tue, 22 Apr 2008 21:15:56 +0200 |
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.