The full history is there. Nothing is destroyed. The goal is to re-baseline the branch, which i accomplish by creating a new branch with the same name which is merged from the original. Thus there is both one check-in containing all past changes made on the branch, and also the branch from which it was derived containing the full history. So you have it both ways, although that fact is secondary to my goal.
Bundles make sense for a totally different use case than I'm dealing with here. Every engineer has developer capabilities, and they directly check in their work onto branches. Because of other company processes with which I must interoperate, I must keep each "activity" on its own branch and reserve trunk for integration consisting of only merges. (Plus I keep several other integration branches for maintaining sync with ClearCase and Subversion which I am also required to support.) And so, I cannot implement updating a branch's effective baseline by merging in outside changes which are not related to the branch's activity. Hence my rebase method. Here's an untested example. I'm using my phone to write this, sorry. # Create repository f new food.fossil mkdir food cd food f open ../food.fossil # Create main dish echo eggs > breakfast f add breakfast f commit -branch breakfast -m Breakfast echo "scrambled eggs" > breakfast f commit -m "Specify how breakfast cooked" # Create side dish f up trunk echo spam > side f add side f commit -branch side -m "Side dish" echo "fried spam" > side f commit -m "Specify how eggs cooked" # Side is ready for consumption f up trunk f merge side f commit -m "Merge side" # Rebase breakfast to include side f up trunk # (Redundant in this case) f merge breakfast f commit -branch breakfast -m Rebase # Finish making breakfast echo "scrambled green eggs" > breakfast f commit -m "Specify color" # Review all breakfast changes f diff -from root:breakfast -to breakfast # Shows only breakfast, not side # Pull it all together f up trunk f merge breakfast f commit -m "Merge breakfast" On Oct 12, 2016 19:38, "Warren Young" <[email protected]> wrote: > On Oct 12, 2016, at 6:12 PM, Andy Bradford <[email protected]> > wrote: > > > > Thus said Andy Goth on Wed, 12 Oct 2016 16:25:43 -0500: > > > >> Comments? Questions? This method does everything my team needs. > >> Perhaps Fossil might consider adopting it, or a streamlined variant, > >> so we'll have an answer to the perennial question about how to do > >> rebase. > > > > I honestly have not yet found the need for ``rebase'' so I'm not really > > sure what I get out of using it. Maybe you can put up a demo Fossil > > repository that shows just what your rebase looks like, and then what it > > would look like without rebase? > > That, or just a command sequence whereby one could construct such a > repository locally. > > I *think* I see what you’re trying to accomplish here, Mr. Goth, but I’m > not quite sure it’s the same thing as Git rebase. For one thing, doesn’t > it leave a branch and all of its checkin history behind? I thought its > most famous use was to collapse a branch’s entire change sequence down to a > single patch. > > Incidentally, as one who ran an active open source project, I always hated > receiving big-ball-of-hackage patches that changed several essentially > unrelated things. I really don’t understand the charm in receiving a > single flattened patch. Fossil bundles are a much better idea. I *want* > to see the full checkin history. > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
