automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] depcomp: recognize tabs as whitespace in the dashmstdout mod


From: Eric Blake
Subject: Re: [PATCH] depcomp: recognize tabs as whitespace in the dashmstdout mode
Date: Fri, 03 Feb 2012 11:42:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]