Commit objects in Git are like manifests in Fossil, their id is the hash of their contents, so "squash", "split", and "reorder" all end up creating new commit objects with different ids. After a rebase, brach points to the new most-recent commit produced. I'm pretty sure the old commit objects are still around and will only disappear if they aren't part of some other branch and you do a gc.
I think if you pull a rebased branch, you can get an error if the commit your branch is no longer in the branch history, at which point you have to decide what to do -- I think you can force the pull, if you want to. If you made changes on the branch, you'd probably have to tag and merge to get it into the new version of the branch. On Fri, Sep 14, 2012 at 12:03 PM, 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? > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
