Branches to patches

[martin f krafft]

also sprach Yaroslav Halchenko <debian at onerussian.com> [2008.04.04.0315 +0200]:
> But in this case for feature branches imho a branch without multiple
> merges from upstream branch looks much cleaner and it is easy to rebase
> it if needed against any ref in repository (e.g. you need to apply that
> branch to test if it solves issues in the maintained version of package
> within etch) -- another option would be cherry picking but rebasing
> would be cleaner imho and easier.

Both rebasing and cherry-picking don't work well with published
repos because they change commit IDs. For everything you publish,
just stick to merging. This is my suggestion and your mileage may,
of course, vary.

Cherry-picking is great for pulling individual commits from
upstream.

Rebasing is great to keep the stuff you work on up-to-date with what
others are doing, and to minimise diffs between upstream and your
working, throwaway branch. It is *not* suitable for cooperation.

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"nothing can cure the soul but the senses,
 just as nothing can cure the senses but the soul."
                                                        -- oscar wilde
-------------- 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/20080404/c44f6e22/attachment.pgp