Re: bug#13578: [IMPORTANT] Savannah issues

[Stefano Lattarini]

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).

> 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'.

> 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'.

>   $ 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.

> 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.

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 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
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.

> [SNIP]

Regards,
  Stefano