automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#13578: [IMPORTANT] Savannah issues


From: Stefano Lattarini
Subject: Re: bug#13578: [IMPORTANT] Savannah issues
Date: Mon, 25 Feb 2013 10:16:54 +0100

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

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

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

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.

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

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

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

HTH,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]