Re: [fossil-users] Rebase solved

[Andy Bradford]

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=144565807936766=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

[Nikita Borodikhin]

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

Re: [fossil-users] Rebase solved

[Andy Goth]

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

[Andy Bradford]

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

[fossil-users] Rebase solved

[Andy Goth]

Forget all about that "isolate" merge stuff I proposed a few months ago. I
could not get comfortable with the heuristics. The overall system would
have been complicated, difficult to understand, and unreliable. After some
experimentation I found another approach that works perfectly for our needs
without any changes to Fossil.

So, what are those needs? Two things. One, we need "f diff branch-name
-baseline root:branch-name" to include only the changes that were made to
address the requirement, discrepancy, feature, etc. for which branch-name
was created. Two, we need to occasionally refresh a branch to include work
that was done elsewhere.

If not for the first requirement, we'd meet the second by merging trunk
into the branch, but we can't. Hence, rebase.

My solution is this sequence of commands:

f up trunk
f merge branch-name
# (resolve any conflicts)
f commit -branch branch-name -m Rebase

This creates a new branch named the same as the old but with an updated
baseline. The collection of changes in the new branch's commit is exactly
the collection of changes that previously existed on the branch. Thus, our
requirements are met.

Fossil usually, but not always, displays the old branch as the primary
predecessor, even though the manifest shows trunk as the primary
predecessor. This "bug" is convenient because it matches our user desire of
presenting the new branch as a continuation of the old.

Let's compare to git. The rebase commit rolls up all the changes into one,
albeit relative to the new baseline, so this is like git. But its manifest
does identify the prior like-named branch which shows all the individual
changes, as is of course how we want Fossil to work.

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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users