Importing projects into depot

Before importing an existing git-based project into depot, a few questions need to be answered:

Is the project licensed under a free software license, or public domain?
Do you need to import existing history?
Do you need to export new history with hashes that continue on from the old history? (e.g. importing an existing repository, and exporting from depot to the old upstream)

Think about this and then pick an approach below:

Import with no history (just commit)

Simply copy the files to where you want them to be in depot, and commit. Nothing else to do!

Import without continuous history (subtree merge)

This import approach lets you drop an existing project into depot, keep its existing history, but not retain the ability to continue external history.

This means that if you, for example, import a project from a different git host using this method, and then continue to commit to it inside of depot, you will not be able to export a history consistent with your previous hashes using josh.

Commit hashes before the import will exist in depot and be valid.

Still, this approach might be viable if a project "moves into" depot, or has nothing depending on it externally.

Pick a location in depot where you want your project to be ($loc from now on).
Fetch your project into the same git store as your depot clone (e.g. by adding it as an upstream and fetching it).
Pick the commit you want to merge ($commit from now on).
Run git subtree add --prefix=$loc $commit, which will create the correct merge commit.
Ensure Gerrit knows about your commit for the parent that is being merged.
Modify the merge commit's message to start with subtree($project_name):. Gerrit will not allow merge commits that do not follow this format.
Push your subtree commit for review as normal.

Import with continuous history

This approach imports the history using josh, which means that external history before/after the import is consistent (you can continue committing in depot, export the history back out, and from an external perspective nothing changes).

This is what we did with repositories like nix-1p and nixery.

Note: Inside of depot, the pre-import commit hashes will not make sense. josh will rewrite them in such a way that exporting the project will yield the same hashes, but this rewriting changes the hashes of your commits inside of depot.

Pick a location in depot where you want your project to be ($loc).
Fetch your project into the same git store as your depot clone (e.g. by adding it as an upstream and fetching it).
Check out the commit you want to merge into depot.
Run josh-filter ":prefix=$loc", and take note of the FILTERED_HEAD ref that it produces ($filtered from now on).
Ensure Gerrit knows about the filtered commit.
Merge the filtered commit into depot using a standard merge, but make sure to add the --allow-unrelated-histories flag. Your commit message must start with subtree($project_name):, otherwise Gerrit will not let you push a merge.
Push the merge commit for review as usual.

Preparing merges in Gerrit

When pushing a merge to Gerrit, it needs to know about all ancestors of the merge, otherwise it will try to interpret commits as new CLs and reject them for not having a change ID (or create a huge number of CLs, if they do have one).

To prevent this, we have a special git ref called subtree-staging which you can push external trees to.

Access to subtree-staging has to be granted by a TVL admin, so ping tazjin, lukegb, flokli, sterni and so on before proceeding.

Determine the commit you want to merge ($commit).
Run git push -f $commit origin/subtree-staging (or replace origin with whatever the TVL Gerrit remote is called in your clone).