On 12 October 2012 00:21, Ron Wilson <ronw.m...@gmail.com> wrote: > > I would think that rebasing would do the same number of merges, just > that it automates those merges. >
Yes, that's what rebasing is. Also rebasing based development process keeps branches shallow and the case with commits interleaved wildly does not really happen. Note that you rebase against upstream that is independent of your branch so the case when you merge upstream into your private branch does not really happen. Upstream can at times include some of your commits which are then eliminated from your branch on rebase because they are already included in the upstream branch. The thing what rebase gives you over single merge are readable patches that are either accepted and included at the tip of upstream or can be applied on top af a release tarball or can be basis for furthere development. With single merge you get a huge merge commit which can be used the same way except it makes no sense on its own, can't be separated into incremental changes that make sense, and when you base further developmnet on top of it (eg. the merge was rejected by upstream) you get those long branches that plug into ancient project history with wildly interweaved commits. Thanks Michal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
