On 9/14/12, Michal Suchanek <hramr...@gmail.com> wrote: > On 14 September 2012 20:10, Jacek Cała <jacek.c...@gmail.com> wrote: >> I don't understand. Without rebase you just merge the other branch >> (D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts >> and end up in the same point, ok with one more commit which is the >> merge of F to Z. > > Except with a merge of F-Z you get a single commit which is often huge > patch of no value on its own. To understand what it does you have to > review the whole branch before the merge possibly with numerous > intermediate merges.
What times did D, E and F take place relative to X, Y and Z? Simplest case, merge X into F, creating X', then commit X' as child of F. Then Y into X' and Z into Y', leaving a commit history of A, B, C, D, E, F, X', Y', Z'. Alternating case: Merge X into D, commit X'. Then Y into (E into X'), commit Y'. Then Z into (F into Y'), commit Z'. Which is 2 extra merges. I think this would be the worst case without involving reordering. For the given example of Z being a fix to X: Merge (Z into X) into D, commit X'. Then Y into ((F into E) into X'), commit Y'. Still 2 extra merges. (If you don't "squash" Z into X, then is same as the previous case except swap Y and Z.) I would think that rebasing would do the same number of merges, just that it automates those merges. I think a rebase script that uses Fossil would need to: List "new" commits in time order Allow user to alter order and specify any desired squashing. Perform merges as needed, pausing as needed to allow user to resolve conflicts. How close am I to what "git rebase" would do? _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
