On 14 September 2012 20:10, Jacek Cała <jacek.c...@gmail.com> wrote: > 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.
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. With rebase you get patches that become part of single, linear history. You can pick only some patches from the start and when there are no interdependencies even just patches from the end or middle, even outside of VCS on top of unpacked release tarball. > >> 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? It just makes following the development history more difficult. And when it does not pass the review for the first time it's not going to be just a simple short branch. Especially if you merge, then fix some bugs in stuff before the merge and add fixes as new commits, then merge again, and repeat a few times. Spaghetti. > >> 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. Of course, that's why there is a distinction between 'public' and 'private' branches. You should state when a commit is part of an 'official' history and should no longer be edited. Thanks Michal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
