> Both rebasing and cherry-picking don't work well with published
> repos because they change commit IDs.
I don't see why cherry-picking is an issue -- it just replicates commit
(patch) into current branch from another branch. It is quite different
from rebasing where commits are moved, thus ref for that branch is
changed in non-fast-forward fashion

> Cherry-picking is great for pulling individual commits from
> upstream.
or introducing individual commits back into upstream (if you are
upstream and want to cherry pick individual fixes from some feature
branches of debian-fixes branches)

> 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
imho diff should (must) stay the same if you are diffing head of
upstream (or the latest split point, ie the point where upstream was
either merged from last time, or rebased against) and the feature
branch regardless if you kept feature branch under constant rebasing or
merging from upstream.

Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik        

Attachment: signature.asc
Description: Digital signature

vcs-pkg-discuss mailing list

Reply via email to