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

Reply via email to