Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> >That diff is between two different revisions on the vendor branch (1.1.1.1
> >and 1.1.1.2, a.k.a. "Initial import of beta340" and "Import of 344").
> >Revision 1.1.1.2 is correct for all relased tags since 3.7.0, but I
> >suspect the general plan of "what happens on a vendor branch, stays on a
> >vendor branch", fails here.
> 
> Agreed.  This is a consequence of reposurgeon choosing to place that 3.7.x
> branch somewhere other than the trunk at (what I believe should be)
> 
> Date:   Thu Jan 14 19:35:52 1999 +0000
>     New file.
> 
> Lars created that branch, 1.1.1, near the start but didn't use it for much,
> apparently.  The branch-master is based on 1.1:
> 
> ----------------------------
> revision 1.1
> date: 1998/04/15 19:16:41;  author: lhecking;  state: Exp;
> branches:  1.1.1;
> Initial revision
> ----------------------------
> 
> I confirmed there are no comments "# HBB: revised etc." in the master branch
> which matches Lars' CVS repo.
> 
> So there are two things going on, basically the same principle.  Some
> differences in branch-3.7.7 hang around if rebasing after the fact. Some
> differences at the very beginning of the master branch get propagated. When
> we compare across the two branches trying to find the graft location for
> 3.7.x series, its a combination of differences.
> 
> Can Reposurgeon force branch points at the start, as opposed to doing
> rebasing?

I don't understrand your terminology.

It's not at all difficult to rebase a branch root, if that's what you're asking.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.