Re: bug#13578: [IMPORTANT] Savannah issues

[Peter Rosin]

On 2013-02-26 19:30, Stefano Lattarini wrote:
> Hi Peter.
> 
> On 02/26/2013 12:53 AM, Peter Rosin wrote:
>> On 2013-02-25 10:16, Stefano Lattarini wrote:
>>
>>>
>>> Note that the users can avoid branch-rewriting issues by renaming their
>>> 'master' to 'next' and their 'maint' to 'master' before pulling.  This
>>> should probably be stated in a message (on list *and* on savannah news)
>>> advertising the new versioning and branching scheme (message not yet
>>> written; it will be once the current issue is sorted out).
>>
>> Hiding stuff like that in some documentation or on a mailing list will
>> not help. You should make it *easy* for people to work on and contribute
>> to automake. Forcing everyone to do a bunch of silly boring renames
>> is not *easy*. It's an obstacle, and obstacles make people nervous
>> and uneasy. Not good, and no, you can't document it away.
>>
> You might have good points, and possibly even be completely right...
> But I must ask, why didn't you step up during the lengthy discussion
> about this change, nor objected during the delay (almost a week) that
> was deliberately let pass between the decision and the implementation
> -- precisely to let this kind of late objections to come out?  What is
> the point of having such discussions in the first place, if people who
> oppose a proposed change (maybe even on solid ground and with sound
> reasons) only object *after* the change has been discussed, accepted
> and implemented?

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.

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, 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"
  $ 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

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

>>>> It's quite hostile to do non-fast-forwards
>>>> on branches as central as master and maint. And I think git/savannah
>>>> is rejecting them quite rightly!
>>>>
>>> Savannah is rejecting all non-fast-forward pushes (which I find annoying);
>>> but it didn't prevent me from deleting and recreating maint, a change that
>>> will still appear as a non-fast-forward to any clone of our repository.
>>>
>>> The reason it doesn't allow me to delete master as well is that doing so
>>> would prevent a "git clone" from checking out the sources of a freshly
>>> cloned automake, which can be very confusing (and of course, git cannot
>>> be aware of the fact that I intend to re-create 'master' just after
>>> having deleted it).
>>
>> The reason is irrelevant. non-fast-forwards of central branches is evil.
>>
> Mostly, yes.  This time, considering that no commits were actually being
> dropped or rewritten, I believed it wasn't not that bad, and was IMHO
> justified by the new improved versioning and branching scheme.
> 
> And while you *might* have changed my mind before (because you have
> valid points, and maybe it would have better to err on the side of
> safety), I have now already rewritten maint, so rather than messing
> up by rewriting it again (to its old value, granted, but a rewrite
> nonetheless) and reverting an already made decision (and made after
> considerable discussion and not negligible efforts), I'd rather stuck
> with the current minor "mess".
> 
> That said, if it turns out that I'm in minority in supporting such an
> approach, then feel free to revert the maint rewrite [1] (and I'll drop
> the planned master rewrite); I'm not here to forcibly impose my will
> on the majority, at least not when the majority has good points or
> valid concerns.
> 
>   [1] And rename the bug-fixing branch to something like 'fix'
>       or 'micro', and adjust HACKING accordingly -- with a clear
>       and explicative commit message.
> 
> Whatever the result will be, I'm starting to lose faith in the
> usefulness of having lengthy discussion for controversial changes
> beforehand; if we don't and I just go ahead with my idea, some (or
> most) people will complain after the fact; if we do, and a consensus
> is reached and implemented, some people still complain after the
> fact.  Not a great situation, motivational-wise ...

The branch rewinding was not discussed at all, I don't think anyone
even realized it was on the map. Personally, I couldn't care less if
the next major is called 1.14 or 2.0, so I felt I had nothing to add to
the discussion.

>>>> master and maint have never been published as "rewindable", and it should
>>>> be correct to base new work on them. They should be left alone, IMHO.
>>>>
>>> Their content has been left alone in fact; it's their "name" that hasn't.
>>>
>>>> You should have implemented this more gradually, such that next would
>>>> have taken its role directly, but maint and master should have been
>>>> allowed to grow into the correct branches once the relevant releases had
>>>> been made.
>>>>
>>> This would give a very confusing interim period IMHO.
>>
>> Yes, confusing. Changes like this cause confusion.
>>
>>> However, note that that we can still implement such a "gentler transition"
>>> (for 'master' only) if you really want to, by using a new branch name
>>> (maybe 'current' or 'devel') instead of 'master', keeping 'master' as a
>>> temporary "alias" to 'next' until the 2.0 release (at which point all of
>>> 'maint', 'master' and 'next' will be fast-forwarded to the commit that
>>> implements the 2.0 release).  I still prefer to pull this sore tooth out
>>> right now, though.
>>
>> So messy.
>>
> Indeed.  Better be consistent and rewrite 'master' too.
> 
>>>> Or even better, implement the change right after a major
>>>> release so that master and maint would have been correctly positioned
>>>> from the start.
>>>>
>>>> I have a few single-commit local branches that I will simply have to
>>>> cherry-pick to the new world order.
>>>>
>>> No, just rebase them on the new name of the branch they were based on;
>>> that is, if they were based on 'master', they are now to be considered
>>> based on 'next', if they were based on 'maint', they are now to be
>>> considered based on 'master', and if they were based on 'branch-1.13.2'
>>> they are not to be considered based on 'maint'.
>>
>> ( s/are not to/are now to/ )
>>
> Yes, sorry for the typo.
> 
>> Yes, that works. But it is a nuisance.
>>
> Yes, but an easily bearable one IMHO.

Obviously. You have already updated to the new world order, so of course
it's easy for you to bear it. It's relatively easy for anyone that's
aware of the branch rewrite, but you simply can't get the message out
to all parties. Also, at no point have you described how a git newbie
should adjust the local repo, that git fetch is needed because git pull
simply will not work etc.

>>>> Or is there some better way to move
>>>> these branches after their base has been pulled from under them?
>>>>
>>> The good thing is that is has not been really pulled away, just *renamed*.
>>>
>>> Remember that Git branches are just "movable tags" basically, so as long
>>> as you have another "handle" referencing the same commit a branch points
>>> to (be that a tag or another branch), nothing is lost by removing the
>>> branch -- you are just removing a tag, not any "real" content.
>>
>> Yes, but the "renames" are extremely surprising to a casual contributor.
>>
>> What if someone has a few commits on, say maint, from before your rename.
>> This someone didn't bother to create a topic branch for these commits
>> for some reason. What happens when those local commits have been forgotten
>> and the new-world-order is pulled? A merge is attempted of the local commits
>> and the whole difference between old and new maint. That is likely to
>> result in a conflict. So, our imaginary dev restores the local maint and
>> puts the local commits on a topic branch and retries only to again see
>> a conflict when the pull is attempted. I bet the poor dev will not first
>> think that upstream has messed up, but that it is some local crap that is
>> happening. How much time will be wasted?
>>
>> BTW, just to test this I did the perfectly valid (no local commits on
>> maint):
>>
>> git checkout maint
>> git pull
>>
>> And my repo is now in a mess with unresolved conflicts. This rename
>> is a mess. It is only clean for you, since it originated from you.
>> Everyone else will have to take about the same manual steps you
>> did in order to follow. Which is crappy and evil and will only work
>> for those of us who pay close attention to the mailing list/docs.
>> The poor sods with a git checkout as of last week but having no reason
>> to pull for some time will wonder what hit them when they actually do
>> pull.
>>
> OK, I thought about those considerations, but the situation seemed much

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.

> less bleak and by no means catastrophic to me; maybe you are right that
> that was only due to the fact that the change originated from myself, so
> I was fully aware of what it would entail, and didn't try too hard to put
> myself in the shoes of casual contributors, who weren't privy to such
> details.
> 
> Then again (pardon me for being whiny) why didn't you object in time?
> Sigh ...

As stated in my original complaint: "I was not aware that those moves
would be non-fast-forwards, and I think ..."

>> Also, git history is fuubared.
>>
> No, having it fubared would mean that at least some once valid SHA-1
> have become invalid; this haven't happen.

Oh, that's perhaps what it means to have the history fubared according
to your definition, but I stated that it was fuubared (with two 'u's,
mind you), which is something completely different according to my
definition. When this change has been forgotten (and it will be), it
will no longer be possible to say what 'maint' was as of 2013-01-15 by
only looking at the git history. You would have to know that a branch
rewrite took place. Ergo, the history has been fuubared.

>> E.g. commit 0756a43c3a77
>> "Merge branch 'branch-1.13.2' into maint" is in fact no longer on maint.
>> How confusing is that?
>>
>>>> Hopefully there isn't some big chunk of unpublished work that will be
>>>> killed by these disruptive changes...
>>>>
>>> No, there is not.  As said, no pre-existing commit has been dropped by
>>> my planned renames.

Cheers,
Peter