thanks! and a tiny comment

[martin f krafft]

also sprach Yaroslav Halchenko <lists at onerussian.com> [2007.10.15.2111 +0200]:
> not conflict with the original patch). So, the patch must not be
> applied any longer. If the branch "build"  is a long lasting branch,
> where merges from feature branches are committed -- it would be the
> place where the patch needs to be "retracted".

git-revert cannot revert multi-parent commits, so you cannot just
undo the merge. However, you can revert all the changes the branch
merged, but you have to do that manually.

This is a very good point and I don't have a real solution to it.

> use case:
>  release x.y.z-1 is in etch (for instance)
>  while working on x.y.z-12 you came up with a patch to security issue,
>  which have to be applied based on x.y.z-1 within a new maint/etch branch.
>  If the solution to the problem was devised as a separate feature branch
>  (e.g. up/fix_overflow_1), it is simply a matter of cherry-picking or may be
>  even merging it into maint/etch branch.
> > Sure, you could use multiple upstream patch branches, but that would
> > make it more cumbersome for your upstream. Also, I tend to prefer to
> > give my upstream one patch per fix, instead of one feature per fix.
> probably I have a bit different understanding of feature branches when
> talking about upstream-patches (or up/* in my workflow) -- every branch
> is either a new feature or simply a fix to a bug ... in both cases the
> full history of that branch defines a single patch over the upstream
> version

The way I would do this is by developing the patch in a branch, but
then squash-commit all your work into a single commit, which you can
then easily cherry-pick. This is easiest for upstream and everyone
else tracking your patches. And it makes sense, for then your fix is
a single commit, not a series of commits. It's still up to you
whether you want to keep the branch around "for history".

> well... I am just trying to expand your guidelines ;-) such
> approach would allow easy and consistent handling of conflicts
> among the patches (if such occur). If there is a superior way to
> resolve it -- I would go for it!

The superior way to resolve conflicts is you, the human being. :)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
a woman is an occasional pleasure
but a cigar is always a smoke.
                                                       -- groucho marx
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20071019/39b237f1/attachment.pgp