Re: bug#13578: [IMPORTANT] Savannah issues

[Peter Rosin]

On 2013-02-27 11:29, Stefano Lattarini wrote:
> On 02/27/2013 10:28 AM, Peter Rosin wrote:
>>
>> [SNIP]
>>
>> The long winding "eyes glossing over" discussion about version numbers
>> had nothing in it about branches, except the initial proposal which
>> stated:
>>
>>        * None of 'maint', 'master' and 'next' should be rewindable.
>>
> It also stated:
> 
>   I also propose the following change to the branching scheme currently
>   implemented in the Automake Git repository:
> 
>   * The 'maint' branch will be reserved to cut of the next micro
>     release; so it will just see fixes for regressions, trivial
>     bugs, or documentation issues, and no "active" development
>     whatsoever.
> 
>   * The 'master' branch will be where the development of the next
>     minor release will take place; that is, a sort of "middle-ground"
>     between the roles so far fulfilled by the 'maint' and 'master'
>     branches in the current branching scheme.
> 
>   * The (new) 'next' branch will be reserved for the development
>     of the next major release; it will basically take over the rule
>     that is currently fulfilled by the 'master' branch.
> 
> I thought that was making clear that the then-current 'maint' and
> 'master' branches would have needed to be renamed in order to implement
> that new scheme.  But re-reading the above, I realize I wasn't making
> that clear at all (it sounded clear to me because the details were
> fresh and clear in my mind then).

It also didn't state *when* the roles would change. The natural point
is after a major release when master and maint have converged
anyway.

>> I was not aware that 'master' and 'next' were rewindable before.
>>
>> Then there was the last message before the implementation that stated:
>>
>>      In a couple of days, I will proceed with this "branch moving":
>>
>>         * branch-1.13.2 -> maint
>>         * maint -> master
>>         * master -> next
>>
>>
>> No other message mentions git branches that I could find, but I might
>> have missed some instance.
>>
>> Now, there are more than one way to "move branches". The most natural
>> is to merge your way forward,
>>
> Not in this case, as 'master' had several commits lacking in 'maint'.

See below.

>> in fact that's the only one that makes
>> sense if the branches are *not* *rewindable*.
>>
>> Thinking about this for a few minutes, I think I would have (with
>> better commit messages):
>>   # create 'next'
>>   $ git branch next master
>>
>>   # update 'master'
>>   $ git branch new-master maint
>>   $ git checkout new-master
>>   $ git merge --strategy=ours master -m "rename maint -> master"
>>
> This would have obtained the wrong effect; what was in master before my
> attempted renaming shouldn't have landed in the new 'master', but only
> in 'next'.  In the new 'master', we only wanted what was in the old 'maint'.

The functional changes would not have appeared on the new branch (due to
the 'ours' strategy), but yes, the commits would appear to be present on
the new branch even if their corresponding changes would not, and I guess
the generated ChangeLog would have been wrong too (listing changes that
simply aren't there).

The nice thing with assigning new roles using merges is that the history
is transparent. It will show exactly what has happened for anyone that can
be bothered to look.

But as I said, I only thought about it for a few minutes...

>>   $ git checkout master
>>   $ git merge new-master # a simple fast-forward
>>   $ git branch -D new-master
>>
>>   # update 'maint'
>>   $ git branch new-maint branch-1.13.2
>>   $ git checkout new-maint
>>   $ git merge --strategy=ours maint -m "rename branch-1.13.2 -> maint"
>>   $ git checkout maint
>>   $ git merge new-maint # a simple fast-forward
>>   $ git branch -D new-maint
>>
> Same issue as above.

Add these "abnormal" merges, and I think all would have been fine
(apart from the generated ChangeLog mentioned above):

$ git checkout master
$ git merge --strategy=ours maint
$ git checkout next
$ git merge --strategy=ours master

But, I don't actually think this branch restructuring was a good
idea at all at this point in time. Branch reorganizations are
better done in conjunction with a new major release.

(BTW, if it was up to me, I would require a really good reason
to ever release a 1.14, given that 1.14 looks like an old style
major release, and has been mentioned multiple times on list,
in commit messages and in code and tests. It's simply best if
1.14 never gets released).

>> Forgive me for assuming that the branches would not be rewound.
>>
>> Also, I was away skiing last week, but I wouldn't have caught this
>> even if I had been "present".
>>
>> BTW, I assume you could still use the mid part to update master, instead
>> of waiting for the savannah crew to help you.
>>
> Of course, we don't need any help from Savannah, since, as I said, no
> commit has been lost.  If you want to revert the botched renaming, you
> just need to rename the current 'maint' to 'branch-1.13.2', and recover
> the previous 'maint' from the last merge into 'master' (that has not
> been re-written), and delete the 'next' branch.

What I meant was that you can use (some of) my above proposed merges
to go forward with the new role for master instead of requiring help
from Savannah to allow rewriting master.

> As I said, if you reach a consensus on that (and I guess you will),
> feel free to go ahead with that.  No objection from me.

You are the maintainer, I'm just stating my opinion. I honestly don't
know what I think is best to do now, when the rewriting has already
started but not yet completed. I guess it's your mess, and I don't
really want to take responsibility for it by stepping in and trying
to clear it up. I.e., I will only offer my opinion at this point.

>> You just have to replace
>> the first "git branch new-master ..." with
>>
>>   $ git branch new-master b4dbcb75
>>
>> (Because I think b4dbcb75 is what 'maint' was before you rewrote it.)
> 
>>>
>>> [BIG SNIP]
>>>
>>> OK, I thought about those considerations, but the situation seemed much
>>> less bleak [SNIP]
>>
>> Why why why didn't you explain that in your rationale when proposing
>> the change? If you truly wanted input, you should have stated the
>> negatives as well in case someone had stronger reasons for being
>> negative.
>>
> Because I mistakenly didn't think they were relevant negatives.  So

I simply don't get that, branch rewriting is just not something you
inflict on your downstream (unless there truly is no other option, or
if you have declared that you would up front).

> new rule for me: from now on, all the negative sides I can think of
> are relevant, no matter how tiny or even "irrelevant" they appear
> to me.

Cheers,
Peter