On 02/03/2012 11:29 AM, Peter Rosin wrote: > Jim Meyering skrev 2012-02-03 19:05: >> Stefano Lattarini wrote: >>> On 02/03/2012 03:51 PM, Peter Rosin wrote: >>>> Wait, there's a (trivial) conflict. But if I resolve that and go >>>> on with the merge anyway we will end up with two different depcomps >>>> with "scriptversion=2012-02-03.12; # UTC". Not good. >> >> I agree that with multiple branches, lines like that >> (as with CVS/Rcs $Id$, $Log$, etc.) guarantee spurious conflicts >> with nearly every merge of that file. Nuke 'em. > > I don't worry at all for Automake proper, but for consumers. > > If I understand correctly, some other projects (at least used to) > pull in depcomp (and other scripts) from the tip of development, > others from the latest release. It is bad if they get different > versions depending on the method they use, and it is good if > we can keep the promise that later versions are always better. > scriptversion="<date>" makes it easy for the external consumer to > verify this. > > This was the explanation given by Ralf a couple of years ago > anyway, if memory serves me right.
Maybe it's worth a custom merge manager that knows how to handle scriptversion lines, to always update it to the current date when doing a merge, similar to how we have a custom merge manager git-merge-changelog for back in the days when changelog was version-controlled (rather than git _being_ the changelog). I'm personally in favor of keeping the date, and keeping it updated to the last action on the file, but also agree that it creates merge conflicts any time development on the file diverges across branches, so removing it won't hurt my feelings, but it will make it harder to tell whether I have the latest version of the script. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
