> 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).

C'mon Bert, it's a basic developer responsibility anyway.  It isn't
any different or more "fragile" than someone committing a version that
didn't merge changes since they started working on it.  Why all these
drama words like "meddling"?  I call it making "quality commits"...

> 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").

Of course merging the latest trunk updates is *implied*, it's a basic
dev responsibility, otherwise what one would be putting into trunk
would not be correct in either case...

> 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.

That sounds great!

> But let's ask David: what is your use case?

I think Dave's use case is the same as when we split Chronology from
Kernel into its own "Chronology" package...