Re: Removing 'scriptversion' from our scripts

[Peter Rosin]

Stefano Lattarini skrev 2012-03-07 08:35:
> On 03/06/2012 10:06 PM, Peter Rosin wrote:
>> Stefano Lattarini skrev 2012-03-06 21:58:
>>> [re-adding the list]
>>>
>>> On 03/06/2012 09:18 PM, Peter Rosin wrote:
>>>>>
>>>>> You also forgot scriptversion...
>>>>
>>> True, but see below.
>>>
>>>> ...which is the reason this change should have been committed on msvc.
>>>> Updating compile/depcomp/ar-lib on maint destroys the rule saying
>>>> "newer is better".
>>>>
>>> But that's a lie anyway when we use multiple branches, as the present
>>> situation shows once again.  OK, enough is enough.  Tomorrow I'll just
>>> nuke all the 'scriptversion' lines from our scripts (in maint and master
>>> as well).
>>
>> It wouldn't have been a lie if changes happened in the right place,
>> at least not for the vast majority of changes, i.e. the backwards
>> compatible ones.  Also remember that the consensus seemed to be that
>> scriptversion is useful last time this came up.
>>
> But that last discussion revolved mostly around issues with spurious merge
> conflicts due to diverging 'scriptversion' lines, which is easily solved
> anyway (just use the date of when you're doing the merge) and is a red
> herring w.r.t. the real problem -- that is, for "orthogonal" branches,
> there is no "newest" version of a script.  If we wanted to be honest in
> declaring the version, we should have a git hook or something similar
> that substitutes the SHA1 and date of the last commit (as reachable from
> the current HEAD) that modified the given script.  Not sure how this can
> be done, or how difficult it would be to do so.

You are making it more complex than it needs to be.  There has been *no*
changes to these scripts that didn't fit on maint (or msvc, since merging
msvc into both master and branch-1.11 but not into maint).  If we just keep
making the changes on maint (or msvc for a couple of scripts) we will have
a linear history and scriptversion will make sense.  But if we can't pace
ourselves and start committing changes to various branches, then of course
scriptversion is doomed and misleading.  But my point is that the changes
that are fit for master/branch-1.11 are always also fit for maint (or msvc).
Well, almost always anyway, but why invent some complex git hook hack for
something that is not likely to ever be needed?

Do you think it would be at all possible to start with a msvc and maint
that is freshly merged into both master and branch-1.11.  Then merge msvc
into maint in such a way that maint resembles branch-1.11, then do dummy
merges of maint into master and branch-1.11.  I.e. for the master case:
    git checkout master; git merge --strategy=ours maint
and similar for branch-1.11.  And then, finally, get rid of the obnoxious
msvc branch...

After that, we should be able to go back to the old simple rule of only
updating the scripts on maint.

Cheers,
Peter