> Out of curiosity (and this is one of the places where I'm just a Git > newbie), why would I ever want to rebase and not merge? I'm currently > merging and it works great. I'm not sure what the advantage of > rebasing instead would be. there are many use cases (there are some in git rebase --help), where rebase is the only option (like moving branch X which is based on Y, to be based on some other branch Z -- for instance feature X is apparently not to be distributed in public domain, thus should be based on branch Y which is for 'private use only', or vise versa -- and for that branch has to be rebased, and if smth was merged into it from X, then rebasing onto Y would bring X into it).
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. Am I missing some other critical use cases? -- 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 _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss