Re: bug#13578: [IMPORTANT] Savannah issues

[Stefano Lattarini]

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?

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

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

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

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

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

Regards,
  Stefano