Hi Eliot, hi Vanessa,

On Fri, Jan 06, 2023 at 04:36:31PM -0800, Eliot Miranda wrote:
> Hi All, Hi Vanessa,
> 
>     does Monticello support the equivalent of git cherry-pick, specifically
> to merge a set of commits from one branch of a package into another?  If
> not, how would I implement it?  Tom Braun and I are working on two
> different branches of VMMaker, his adding incremental old space garage
> collection and compaction, mine regular trunk maintennance.  I want to
> integrate two recent commits of mine fixing a become bug into Tom's
> branch.  Or course I could just file out the changes, but in bringing them
> in there would be no common-ancestor check to show me conflicts.
> 
> I'm happy to use a script-based approach, and would happily pair with
> someone to attempt to implement a UI, perhaps based on a repository
> inspector or history view there-from.

TL;DR use the Version History Browser

I am no expert in the theory, but I do have some hands-on experience.
For some time now, I have been maintaining an update stream at
http://www.squeaksource.com/TrunkUpdateStreamV3 that follows the
real Squeak trunk update stream, modulo whatever changes are specific
to the Spur/V3 image formats.

I originally had intended to do this for a few weeks or months after
we moved to the (hugely improved) Spur image format, but to my
surprise the Montecello tools actually made it very easy to do
the merging and cherry picking, so I never quite got around to
not doing it any more :-)

Basically what I have been doing is this:

Given "branch A" and "branch B" where A is is the real branch
(squeak trunk or VMMaker.oscog for example), and where branch B
is something that more or less tries to follow branch A:

- Use the Montecello history browser as the reference for changes
in branch A.

- Enforce (manually) a numbering convention in which each package
version on my branch B is logically equivalent to the branch A
version of the same number (this makes update streams work nicely,
and it amounts to just a matter of saving version updates in B
with the same version number as the corresponding version in A).

- Given a version on branch B, use the history browser on branch A
to display all of the changes in A version A minus one.

- Load any or all of those changes from the A diff into the current
B branch in image, manually addressing any conflicts ("manually" in
this case being a good thing, as these are things you actually want
to put your eyeballs on).

- The cherry picked changes from A are now in B in your image. Save
them in the B repository. When you do the save, manually edit the
version name with the branch suffix and version number, no big
deal but be careful and make sure to save it to the right repository
with the right branch suffix and version number.

The Version History Browser is the primary tool here, and the key
thing is to use the Version History Browser to cherry pick the
things you want from branch A into your branch B. Along with that,
you can use the "Adopt" and "Reparent" buttons on a Repository brower
if you want to fix up the ancestry for some reason, but mainly it
really is just a matter of cherry picking from the branch A history
browser, and remembering to save updates to your preferred version
branch name and version number.

This might not be elegant or high tech, but I find that it works
remarkably well once you get the hang of it.

For the specific case of Eliot being "branch A" and Tom being
"branch B", I don't know the details but by way of approach
I would be inclined to cherry pick as much as possible from
branch A (Eliot) into branch B (Tom) using the history browser
from branch A to select the changes. Save it in branch B possibly
with "Adopt" version history from branch A if that seems appropriate.
Then reverse the process, and use the branch B history browser
to cherry pick changes back into branch A, possibly with B "adopted"
as an ancestor if that make the version tracking more clear.

Also for the issue of "here would be no common-ancestor check to 
show me conflicts", this is where you may want to use (with care)
the "Adopt" or "Reparent" buttons on a Repository brower.

Just for perspective, I also am a huge fan of git, which is by far
the best version management model that I have ever encountered (*).
But even so, the process of cherry picking changes from the version
history browser in Squeak is hard to beat, and I have never found
anything better in git or anywhere else.

HTH,
Dave

(*) I cannot help but mention that git is astonishly fast and and
the merging functionality is simply amazing, I almost cannot believe
how well it works. It seems to me to be conceptually similar to
Smalltalk in the sense that if you start with a rigorously tiny
conceptual kernel, than all the stuff that eventually gets layered
on top of it (GitHub, Pharo, Etoys, etc) can still end up being fast
and highly functional </EOM>