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

[Peter Rosin]

Eric Blake skrev 2012-02-03 19:42:
> 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.

I don't think that's the right way to go (for Automake).  This has
only come up because we have let the scripts diverge between master
and branch-1.11 in the first place.  In the vast majority of cases
there is no need to have them diverge, it's either bug fixes or
adding new orthogonal stuff.  The major overhauls are rare indeed.

So, if it really is true that some consumers use scripts from the
tip of development and some from the latest release (and we have
seen no evidence to counter that) it will be easier for all if we
can keep the promise that a fresher scriptversion is always better.
Having the scriptversion change on merges (sort of behind the back
of the dev) seems like a way to only make it easier to let them
diverge.  And we don't want that.

Instead, I really think it's best to confess the original mistake,
backport the changes, and go on from there.

I'm not objecting to a git-merge-scriptversion manager as such, but
I just don't think it's appropriate for this case.

Cheers,
Peter