My understanding is that git rebase is used primarily to produce patches to be applied onto a particular tag or checkin of a destination repository, to give the same result as currently in the source repository, but without requiring the destination to do a git pull from the source repo, or to only pull a single prettified branch, rather than the history which made it happen. The source, however must have done a pull from the destination to get the start point of the patch.
The essential feature is that the destination repo is somehow cleaner or of higher status or authority than the source repo. The source repo holds additional private content, perhaps including messy time-consuming development, and pulls at least certain content from the destination from time to time. When the source repo is finally ready to use, the messy development gets repackaged as a simple difference from the current state or some known recent state of the destination. I can't see what a rebase equivalent in fossil might do, which can't already be done using fossil diff (if you really want patches), or using private branches which get merged back into public ones from time to time, with only the public branches available to pull from. The fossil way of doing things (to my understanding) is to expose and preserve all history, while the whole idea of git rebase is to hide some of the history. If you really want rebase, you're probably looking in the wrong place, but I think you can already bend fossil to do it, without needing any changes to the tool itself. -- Christopher Vance _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
