On 14 September 2012 19:03, Jacek Cała <jacek.c...@gmail.com> wrote: > Thanks Bill for the explanation. > > I see private tags as the end result of 'squash' rather than 'edit'. > If you have three commits A-B-C and decide to hide B, you will see > A-C. And then diff between C-A will show combined commits B+C against > A. > > Regarding 'edit' and 'reorder', while 'edit' could be useful, I see > reordering as asking for troubles. I wonder if anyone uses it with > shared repos?
Rebase is often used to bring patches up to date so that they can be efortlessly pulled upstream. You see a repository that has commits A-B-C you clone it and write some changes A-B-C-X-Y-Z but upstream has changed A-B-C-D-E-F 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. 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. 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' Again, you are left with a stump branch. As the stumps thicken you can get quite some jungle. Some filtering to exclude those stumps would help a lot. Thanks Michal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
