> > btw: I'm curious about the "two patches + one more to fix the first two".
> > It is not the usual thing to squash patches before distributing them,
> > particularly when one of them fixes things in the others?
> 
> On [email protected] we send the patches for the commits that we push
> to the master branch.
> 
> Ideally I would have caught the mistake before pushing so I could have 1
> patch per module (sys_stat-h and sys_types-h). But I realized when I was
> replying to your bug report after pushing. Oops...

Aha, should have guessed...

> The correct single patch can be generated using this command in a Gnulib
> checkout though:
> 
>     $ git diff 
> 8ba0c4da1ea978b770d1bbf8e306396ed556205f..d5dcc6c91d3c7c6f293fe906af885831af458dac
> 
> I expect that you do not have it cloned, so I have attached it for
> you. Since m4 (atleast from git) puts Gnulib tests in tests/, I expect
> you can trim the ChangeLog and .texi files and the patch will work.

Oh, thank you. Actually, I had already solved it by applying the three
patches and then doing "diff -ru m4-1.4.20.orig m4-1.4.20". Very often,
there are more than one way to do that sort of things.

I confirm that the non-code parts for the patches do not apply cleanly
to current m4 source, so yes, I will probably skip them.

Thanks a lot.

  • m4 1.4.20 on a... Santiago Vila
    • Re: m4 1.... Collin Funk
      • Re: m... Santiago Vila
        • R... Collin Funk
          • ... Santiago Vila
        • R... Bruno Haible via Bug reports for the GNU m4 macro processor
      • Re: m... Bruno Haible via Bug reports for the GNU m4 macro processor
      • Re: m... Bruno Haible via Bug reports for the GNU m4 macro processor
        • R... Santiago Vila

Reply via email to