Re: [fossil-users] Rebase solved
Thus said Andy Goth on Wed, 12 Oct 2016 20:46:54 -0500: > # Rebase breakfast to include side > f up trunk # (Redundant in this case) > f merge breakfast > f commit -branch breakfast -m Rebase This sounded familiar... I believe we have gone over this particular merge style before: http://marc.info/?l=fossil-users&m=144565807936766&w=2 But, if this works for you in your own code base, Fossil allows you do do it. :-) Andy -- TAI64 timestamp: 400057ff2ece ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Rebase solved
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 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" wrote: > > On Oct 12, 2016, at 6:12 PM, Andy Bradford > 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
Re: [fossil-users] Rebase solved
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" wrote: > On Oct 12, 2016, at 6:12 PM, Andy Bradford > 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
Re: [fossil-users] Rebase solved
On Oct 12, 2016, at 6:12 PM, Andy Bradford 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
Re: [fossil-users] Rebase solved
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? Thanks, Andy -- TAI64 timestamp: 400057fed1aa ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users