also sprach Yaroslav Halchenko <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> : :' : 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
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss