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

Reply via email to