On Thu, 2011-11-10 at 19:07 +0800, Mathieu Bridon wrote: > On Thu, 2011-11-10 at 11:43 +0100, Vratislav Podzimek wrote: > > On Thu, 2011-11-10 at 10:52 +0100, Fabian Deutsch wrote: > > > Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek: > > > > Isn't it better to use 'git rebase'? E.g. on master use 'git rebase > > > > f16'. As I understand it, it would do the same as cherry-picking commit > > > > after commit in these cases. > > > > > > Someone might correct me, but rebasing introduces problems for > > > co-maintainers, if upstream (maintainer) decides to rebase some branch. > > > > > > See http://man.he.net/man1/git-rebase > > Yes, but I don't see any problem in a situation like this: > > > > A--B--C *master > > A--B--C--D--E *f16 > > > > I would expect the result to look like: > > A--B--C--D--E *master > > A--B--C--D--E *f16 > > Yes, in case of such a fast-forward then rebasing gives the same result > as merging. No, you are dead wrong here. Merging does *join* the history of 2 branches in git, and the top commit has multiple ancestors. > Which means it would not be the same as cherry-picking (as you were > saying previously). No, a forward rebase is *exactly* the same as a rebase on top. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
