Eric Blake wrote: > 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).
That would be a fine compromise.
