Hi, this is not a rebase, at least not in a sense of git. Git rebase is, basically, what you would get if you recreate someone's work from diffs published to a mail list. Rebase is an application of all commits, one by one, from old branch to the new parent. After rebase you get a _new_ set of commits with the same commit messages etc in a new branch, which bears no relation to the old one. This is the main criticism of rebase - new commits lose historic context of old commits.
Your proposal is what often called "merge from trunk" or "sync with trunk" or "update to trunk" in svn world. I personally like it more than git rebase. However, it is twisted in a very fossil way. Regular merge would be: * f checkout branch-name * f merge trunk * f commit Nikita On Wed, Oct 12, 2016, 18:46 Andy Goth <andrew.m.g...@gmail.com> wrote: > 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" <w...@etr-usa.com> wrote: > > On Oct 12, 2016, at 6:12 PM, Andy Bradford <amb-fos...@bradfords.org> > 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 > 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 >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users