Subject: bug#13578: [IMPORTANT] Savannah issues

From: Peter Rosin <[email-masked]>
Date: Tue, 26 Feb 2013 00:53:11 +0100

On 2013-02-25 10:16, Stefano Lattarini wrote:
> On 02/25/2013 09:14 AM, Peter Rosin wrote:
>> On 2013-02-23 19:06, Stefano Lattarini wrote:
>>> On 02/23/2013 06:46 PM, Stefano Lattarini wrote:
>>>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote:
>>>>> In a couple of days, I will proceed with this "branch moving":
>>>>>
>>>>>    * branch-1.13.2 -> maint
>>>>>    * maint -> master
>>>>>    * master -> next
>>>>>
>>>> Done.
>>>>
>>> Damn, not really.  For some questionable reason, Savannah is rejecting
>>> my non-fast-forward push to master even if I specify '--force', and
>>> I cannot use the usual trick "delete the remote branch, then push the
>>> local one to it" trick that I typically use to work around this
>>> problem, since 'master' is the "current branch" of the remote
>>> repository, and that cannot be deleted to avoid confusing "git clone".
>>
>> I was not aware that those moves would be non-fast-forwards, and I
>> think this is bad bad bad.
>>
> 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.

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

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

>> 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, that works. But it is a nuisance.

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

Also, git history is 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.