Re: Incorrect merge

[Óscar Fuentes]

"Stephen J. Turnbull" <address@hidden> writes:

>  > Adding an extra branch does not increase the current workload.
>
> Of course it does.  Most occasional developers work only on the branch
> that they use every day, either trunk or stable/maintenance.  That's
> where they test, that's where they refine.  Adding the common-fixes
> branch means they need to clone and maintain that branch, and work in
> a branch that they don't use.

Almost every change on emacs-23 is intended to trunk too. Right now
those changes that are exclusive to emacs-23 must be flagged
somehow. Adding common-fixes just means that people working on emacs-23
will work on common-fixes, except for those cases where they would flag
the change as belonging to emacs-23 only. Not so hard, IMO.

> Even for frequent contributors who help with porting patches back and
> forth between the branches, this requires more thinking about where
> you should do the work.

Uh? With common-fixes you merge the commits there into emacs-23 and
trunk. That's all.

>  > They would commit to common-fixes the same way they do for emacs-23.
>
> You mean, stuff that doesn't belong there, as started this thread? ;-)

The problem was that commits intended to emacs-23 were merged into
trunk. Yes, people can do all kinds of mistakes, but no script will
magically avoid them.

[snip]

>  > when there are standard practices on dVCS for properly solving the
>  > problem at hand.
>
> But there aren't.  Only Darcs supports cherry-picking properly.

You are missing the point. common-fixes will eliminate the need for
cherry-picking (and for examining each commit on emacs-23 before merging
into trunk). The maintainers save time and the VC history is consistent
(with commits maintaining its identity on the branches where they are
installed)

[snip]