My use case is different.

Package Chronology-Core is part of the trunk update stream. Separate from
this, and hosted in a squeaksource.com repository for UTCDateAndTime, I
have a sequence of Chronology-Core versions that ends with a version that
I would like to be able to submit into the existing trunk stream.

Both streams (Squeak trunk and SS UTCDateAndTime) are rooting in a common
version Chronology-Core-cmm.2 of 3 March 2016. Both streams have progressed
in parallel, and are (mostly) functionally equivalent.

I was looking for a way to move the squeaksource.com update stream
into trunk without disrupting the existing update stream. A possible
solution is to re-save the squeaksource.com versions as versions named
'Chronology-Core.UTC-xxx.nn.mcz' rather than 'Chronology-Core-xxx.nn.mcz'.

In order to do this, I loaded individual versions 'Chronology-Core-xxx.nn.mcz'
from the squeaksource repository, then saved them as equivalent
'Chronology-Core.UTC-xxx.nn.mcz' versions in a local repository on my PC
(that could later be copied to inbox or trunk if the experiment works).

As part of this process, it was necessary for me to load from one
repository, then save to another using the '.UTC' naming. In order for
this to work, I needed to be able to reparent the new '.UTC' version to
its immediate predecessor in the new repository. This retains the '.UTC'
naming throughout the new repository version histary, and results in
a sequence of 'Chronology-Core.UTC-xxx.nn.mcz' versions in the new
repository that is equivalent to the original, but separate from the
naming conventions of the Squeak trunk update stream.

This is probably not a common use case ;-)

Dave


On Tue, Nov 06, 2018 at 02:12:19PM -0800, Bert Freudenberg wrote:
> I can see that use case, but meddling with history / parentage is not the
> right way to do it IMHO. (even the "adopt" button is questionable, except
> in very limited circumstances) It's too easy to lose changes that way -
> anything that happened in trunk up to this point from when you branched off
> would be lost (or it would be the responsibility of the developer to make
> sure this is not the case, which is way too fragile).
> 
> The "standard" way to do this is to do a "merge-and-squash" (standard as
> in, accepted practice in other developer communities, e.g. "git merge
> --squash").
> 
> This is like a merge (meaning it combines changes from both trunk and your
> line of commits) but throws away all the intermediate commits, "squashing"
> all the changes into one single merge commit. That means you can commit as
> much and as often as you like, but when merging it into trunk, it is only
> seen as one commit.
> 
> But let's ask David: what is your use case?
> 
> - Bert -
> 
> 
> 
> On Tue, Nov 6, 2018 at 10:37 AM Chris Muller <asqueaker at gmail.com> wrote:
> 
> > You read my mind!  I didn't review or test it, but I was already
> > thinking about this functionality to help us with Inbox submissions as
> > well.
> >
> > What I would like to propose is that we feel the need to rapid-fire
> > multiple versions into trunk, to do it into Inbox instead, and when we
> > have the final one ready for trunk, adopt the top version in trunk as
> > the sole parent so that we can see just the _true_ change from the
> > prior version, without all the noise of the "interim" changes.
> >
> > I even think the user should be prompted to do so, but one step at a
> > time...
> >
> > Best,
> >   Chris
> > On Mon, Nov 5, 2018 at 10:20 PM Eliot Miranda <eliot.miranda at gmail.com>
> > wrote:
> > >
> > > Hi David, Hi All,
> > > On Mon, Nov 5, 2018 at 7:53 PM <commits at source.squeak.org> wrote:
> > >>
> > >> David T. Lewis uploaded a new version of Monticello to project The
> > Inbox:
> > >> http://source.squeak.org/inbox/Monticello-dtl.685.mcz
> > >>
> > >> ==================== Summary ====================
> > >>
> > >> Name: Monticello-dtl.685
> > >> Author: dtl
> > >> Time: 5 November 2018, 10:52:58.748205 pm
> > >> UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8
> > >> Ancestors: Monticello-eem.684
> > >>
> > >> MCVersionInspector has an 'Adopt' button to allow the selected version
> > to be added to the parent or parents of a working version. Provide a
> > 'Reparent' button to allow a selected version to become the sole parent of
> > a working version. Adjust defaultExtent to accomodate the additional button.
> > >
> > >
> > > Nice.  It is for someone like Bert to review and accept this but this
> > seems a very useful addition to me!
> > >
> > >>
> > >>
> > >> Motivated by the exercise of preparing to copy Chronology-Core versions
> > from one repository into equivalent Chronology-Core.UTC versions in another
> > repository (possibly trunk). In this scenario, it is helpful to be able to
> > reparent a newly loaded Chronology-Core version from one repository to be
> > the child of the last saved Chronology-Core.UTC version in another. The
> > '.UTC' suffix in this case is intended to branch those versions from the
> > trunk update stream, allowing later merge to trunk with branch history
> > preserved.
> > >>
> > >> =============== Diff against Monticello-eem.684 ===============
> > >>
> > >> Item was changed:
> > >>   ----- Method: MCRepositoryInspector>>defaultExtent (in category
> > 'morphic ui') -----
> > >>   defaultExtent
> > >> +       ^600 at 300!
> > >> -       ^450 at 300!
> > >>
> > >> Item was added:
> > >> + ----- Method: MCVersion>>reparent (in category 'actions') -----
> > >> + reparent
> > >> +       "Let aNode be the sole parent of this version"
> > >> +       self workingCopy reparent: self!
> > >>
> > >> Item was changed:
> > >>   ----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic
> > ui') -----
> > >>   buttonSpecs
> > >> +       ^#(
> > >> +               ('Refresh' refresh 'refresh the version-list')
> > >> -        ^ #(('Refresh' refresh 'refresh the version-list')
> > >>                 (Browse browse 'Browse this version' hasVersion)
> > >> +               (History history 'Browse the history of this version'
> > hasVersion)
> > >> +               (Changes changes 'Browse the changes this version would
> > make to the image' hasVersion)
> > >> +               (Load load 'Load this version into the image'
> > hasVersion)
> > >> +               (Merge merge 'Merge this version into the image'
> > hasVersion)
> > >> +               (Adopt adopt 'Adopt this version as an ancestor of your
> > working copy' hasVersion)
> > >> +               (Reparent reparent 'Adopt this version as the sole
> > ancestor of your working copy' hasVersion)
> > >> +               (Copy save 'Copy this version to another repository'
> > hasVersion)
> > >> +               (Diff diff 'Create an equivalent version based on an
> > earlier release' hasVersion)
> > >> +       )!
> > >> -                (History history 'Browse the history of this version'
> > hasVersion)
> > >> -                (Changes changes 'Browse the changes this version
> > would make to the
> > >> - image' hasVersion)
> > >> -                (Load load 'Load this version into the image'
> > hasVersion)
> > >> -                (Merge merge 'Merge this version into the image'
> > hasVersion)
> > >> -                (Adopt adopt 'Adopt this version as an ancestor of
> > your working copy'
> > >> - hasVersion)
> > >> -                (Copy save 'Copy this version to another repository'
> > hasVersion)
> > >> -                (Diff diff 'Create an equivalent version based on an
> > earlier release'
> > >> - hasVersion))!
> > >>
> > >> Item was added:
> > >> + ----- Method: MCVersionInspector>>reparent (in category 'accessing')
> > -----
> > >> + reparent
> > >> +       (self confirm:'Adopt ',self version info name, ' as the sole
> > ancestor of your working copy?')
> > >> +               ifTrue: [self version reparent]!
> > >>
> > >> Item was added:
> > >> + ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet
> > unclassified') -----
> > >> + reparent: aNode
> > >> +       "Let aNode be the sole parent of this version"
> > >> +       ancestors := Array with: aNode
> > >> + !
> > >>
> > >> Item was added:
> > >> + ----- Method: MCWorkingCopy>>reparent: (in category 'operations')
> > -----
> > >> + reparent: aVersion
> > >> +       "Let aNode be the sole parent of this version"
> > >> +       ancestry reparent: aVersion info.
> > >> +       self changed.!
> > >>
> > >>
> > >
> > >
> > > --
> > > _,,,^..^,,,_
> > > best, Eliot
> > >
> >
> >

>