Add some common recipes for downstream users developing on top of the existing git mirrors. These instructions show how to migrate local branches to the monorepo.
|879 ↗||(On Diff #181074)|
|908 ↗||(On Diff #181074)|
Perhaps adding somewhere before or after this elaborate explanation that the script also supports migrating other types of mirrors/repos would be enough to cover those cases (like migrating lnt/test-suite/etc forks). It was very straight--forward in my experience so built in help should be enough.
I think this complex task of migrating a downstream fork with important history should go into its own document, with just a reference here. It's very important for those few who need to do it, but I don't think it'll be something that a large number of people will need to do.
I would expect the *most common* case is just:
There's some outstanding uncommitted work in:
- an SVN checkout, or
- a git clone of the old separate repositories with one or more branches, or
- a git clone of the old monorepo with one or more branches
and I want to keep rebasing it onto master until I can get it committed.
These migration tools are rather scary and overkill for that sort of use.
I could certainly put these instructions in a separate document, but where should it go? This is a one-time operation and so it doesn't make sense to put it in with the regular LLVM docs. It's not a proposal, per se, so I don't think it belongs in docs/Proposals other than as an addition to a related proposal, which is this document.
Do a lot of people use the old monorepo for development? We don't so I haven't developed any process for migrating from that. I'll leave that to someone else to add.
Migrating from SVN is way more painful and again, I'll leave that to someone else to document. :)
Obviously I'm biased, but I don't think these tools are all that scary. git-rebaseing multiple downstream merge commits on top of upstream master is way more scary to me. You need a relatively new git to do it properly and even then I don't know how well it's tested. If the downstream branches don't have any merges it's much easier but how likely is that? We merge from upstream regularly and I know of other downstream users that do the same.
Oh yes, it's 100% the most likely scenario for downstream forks with history (e.g. shared internally to others in their org). But what I mean is that there's a lot of individual developers with their own private work-in-progress local *UNSHARED* repositories and checkouts, which will likely have no (important/intentional) merge commits because they're just working on patches to submit upstream.
Those migrations are going to be the most common, and such people shouldn't think they need to use these migration tools when a simple git rebase or format-patch/apply would likely be more appropriate.
Ah, yes, I completely agree with that. Our developers here are going to want to do that for their own local branches (or we could just force them to push before we migrate) so I have some need to develop a process for them.
Is there anything substantial left here?
Since we already have a blessed repo it makes sense to push this, even if it is not 200% ready.
|914 ↗||(On Diff #181136)|
Does it make sense to add --source-kind=split argument to migrate-downstream-fork.py here?
Anyway, just checked this recipe on our simple downstream repo (that is a split kind that has only llvm project in it).