branches, and, well, more branches (was: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.)

[Ralf Wildenhues]

* Peter Rosin wrote on Thu, Sep 16, 2010 at 11:18:53AM CEST:
> Den 2010-09-15 23:56 skrev Ralf Wildenhues:
> > Peter, you shouldn't have to worry about any merging issues.  That's
> > what working on a branch is for, and that's what the msvc branch is for.
> > 
> > Irrespective of which branch gets merged to master in what order, that
> > doesn't necessarily mean the last one to merge gets the burden to fixup.
> > In case of doubt, the maintainer does.
> 
> Ok, good!
> 
> > By the way, if a merge requires more than trivial cleanup, it's probably
> > not the cleanest idea to do a fake merge, but to do the cleanup in a
> > separate patch beforehand, or to merge the other way first or so.
> 
> But if we merge the other way first (master into msvc), then we lose
> the possibility to merge msvc into maint.

That would be fixable: we branch msvc-script (or msvc-maint) off of
msvc, do above cleanup on the latter only.  Be sure the former has all
the scripting and other maint-suitable work, and is fully merged into
msvc.  Profit.

> Not that we'd want this
> patch in maint anyway, but you said at one point that it would be odd
> to not release bleeding edge versions of auxiliary scripts, and the
> simplest way to achieve that would be to merge msvc into maint and
> branch-1.11 when the time comes.

I still follow this idea.

I guess my point is that all of these things are fixable, as long as the
original approach used enough separate branches and based them off of
the oldest ancestors in question.

> I guess the correct thing to do is to do any future changes for compile
> and ar-lib on some branch that does not have this AM_PROG_AR patch?

Right.

> Or
> should we merge from the current msvc (i.e. w/o AM_PROG_AR) into maint
> and then cherry-pick any changes that are on top of this patch but
> still desired for maint?

Cherry-picking is for when we have messed up already.  ;->

Cheers,
Ralf