[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `bu
Gary V. Vaughan
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
Wed, 2 Nov 2011 08:44:19 +0700
On 1 Nov 2011, at 22:03, Eric Blake wrote:
> On 11/01/2011 08:19 AM, Gary V. Vaughan wrote:
>> This next series of changesets is the beginning of modelling the directory
>> and filenaming conventions of Libtool to match what is done by other
>> prominent GNU projects... this means that gnulib scripts will require less
>> tweaking and configuration, so we can use them in the configuration in which
>> they have been most widely tested and debugged. Also, it makes everything
>> look more familiar to anyone coming from another GNU project who is hoping
>> to generate some patches for us... and every little thing we can do to reduce
>> friction in that process is a net win as far as I am concerned.
>> I've attached the full patch which is ridiculously large for a simple
>> directory move and fixing the fallout in the files that care.
> Next time, when sending a file rename patch, consider using 'git
> format-patch/send-email -M -C'
Ahah! I suspected it must be possible, because tig displays patches in that
much shorter format by default, but I didn't think to chase down the right
flags. Thanks for the hint :)
> , which finds moves and renames and compresses them into a much smaller patch
> output that names just the old and new file name and any incidental
> differences between the two files (if I understand git correctly, the only
> reason the smaller patch is not default is because it takes a bit more
> processor time to determine file similarity and because it was not understood
> by patch(1) back in the days when git used patch rather than its own tools
> for parsing changesets; but I don't ever notice the difference, and
> definitely appreciate the smaller diffs).
> Or make those options permanent for your git setup, with 'git config --global
> diff.renames true'.
> At any rate, I'm certainly in favor of this series, in the name of easier
> maintenance, although I didn't review it closely.
Me too... I'm kinda surprised at the amount of cruft libtool is carrying around
right now, and moving decisively towards a gnulib based build is the perfect
opportunity to spring clean :)
Gary V. Vaughan (gary AT gnu DOT org)