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

Reply via email to