2012/9/14 Michal Suchanek <hramr...@gmail.com>: > > so you do a rebase so that your commits can be applied on top of F and > send then for review: > > A-B-C-D-E-F-X'-Y'-Z' > > If there are no conflicts between your changes and upstream this is > fine, otherwise you have to resolve them somehow, and upstream then > does not have to. They get nice linear history.
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. > This leaves behind a hidden stump with the original X Y and Z commits > in git. In fossil the stump would remain and you would have to go out > of your way to hide it or not upload it during push. Is a short branch in the timeline such a bad thing really? > Also if Z is really a fix for a bug in X which is not upstream yet you > might want to do an edit - swap Y and Z and squash X and Z so that the > upstream reviewer has easier job reviewing fewer patches. > > A-B-C-D-E-F-X'Z'-Y' That might be useful. But what if someone was tempted to do this for a fix to a patch that was done 100 commits earlier... Might become tricky I suppose. Cheers, Jacek _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
