On 05/28/2013 11:30 AM, Paolo Bonzini wrote:
Il 27/05/2013 23:11, Adam Williamson ha scritto:
As soon as your
f19 build diverges from master at all, merging becomes inappropriate
(and probably impossible) and you should instead use 'cherry-pick'. It
helps to have at least a vague overview of how git is designed to be
used, and what is the actual _point_ of the commands you're using in the
intended git workflow.
Interestingly, git itself is developed the other way round: you first do
the fixes in the oldest applicable branch and "git merge" upwards (from
f18 to f19, from f19 to master in the Fedora case).
That's because there's little support in VCS for backporting. The VCS
doesn't know if the new development in master is part of the fix, or
unrelated new development. The only system I've ever used which had
some support for this was darcs, but more often than not, I had
unintentional patch dependencies on new development I didn't want to
backport, so it didn't work out that well.
The forward-porting approach has the risk that it stops before reaching
master, so users will encounter regressions when updating. And both
approaches do not really mix that well because merging from the stable
branch with cherry-picked and massages backports tends to conflict a lot.
Better tool support for backporting and the more general issue of patch
stacks (like we have in RPM and Debian packages) is very desirable, but
it's a really difficult problem.
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
