Hi Eric, 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'. Done. > 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 :) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
