M2g release of base doesn't merge cleanly with M1m release of base.

[aryairani]

This is going to be true as long as the upgrade-codebase command rewrites the history; basically M2g doesn't have a common history with M1m anymore.

Options:

1. Change upgrade-codebase to not recompute hashes; this would probably be fine, and would ease the transition for v1 users

   • Some merge surgery on base may be required to repair things so we get clean merges, given that multiple versions of M1m base would now exist, and because people may already have merged M2f or M2g in with their M1m base.

2. Not do anything special besides telling people to delete their old .base and/or not merge old base with new base.

[pchiusano]

My view is that release namespaces aren't meant to be merged - they don't even have any history currently, it's just a squashed namespace! Merging namespaces is a thing you do during development, like for a series namespace or a PR.

Even if we did want to do some history-aware merging of releases, that doesn't do anything to help upgrade code written that depends on the old version of base. You need to apply patches for that.

So, my recommendation is to pull to a new namespace base_v2 and then (if you want) delete the old, possibly after applying a patch to upgrade code some that depends on the old version. You could also rename base to base_M1m if you want and pull to base. This is also suggested in the M2 release notes #1930.

I think archived namespaces will help, like you'll archive old versions of libraries you aren't actively using any longer.

Aside is maybe we need to make pull command less error prone, it's easy to make a mess merging unrelated things. Have some ideas on that.

[aryairani]

I see it in the release notes now. Adding some safeties on pull and merge sounds good.

I think folks might expect to be able to pull a newer version onto an older version and end up with the latest, like you typically can with git; at least, I did! But maybe updating pull is enough.

[pchiusano]

Yeah perhaps the issue is we're using pull for library installation and also library development even though they are different. 

Like when you do a git pull, that's pulling in all the history - which makes sense for doing development, and merging to the destination also makes sense in that context... whereas I don't think you want to pull in all the history of libraries you are using... if everyone does that then all history ever makes its way into one repo. Maybe with partial history that could be okay, but it still seems a bit weird.

With libraries you usually don't want to upgrade them in place also, since code may still be referencing the old version unless you explicitly apply some patches or make code changes.

I feel like we could use some specialized separate commands for library install (it could put it in a standard location with a standard name) and library upgrade vs using pull for everything.