Question: Regarding Deterministic Checkouts

[tcardlab]

🤓 Question

First of all, thank you for creating such an elegant solution to the multi/mono-repo problem and maintaining it through a stable state for all these years.

I'd like to revisit the issue of the deterministic checkouts, as it's been the only functional counter argument from other team members, and I admit it seems useful for the following situations:

1. Bisecting all repos to determine when a bug was introduced without the added noise or work of discerning whether all sub repos are compatible at each point.
2. If I tell someone to check out a commit, it's good to automatically ensure we are discussing the exact same state.

Despite prior discussions on the issue (229), I have not been able to find any plugins or forks that address this. Should I have to roll my own solution, what route would you suggest is most appropriate?

Brainstorming

---

Many of these approaches depend on the fact that all child repos are committed before the top-level repo in order to get their commit hash (eg. meta commit --exclude-only . && (find and record hashes) && meta commit --include-only . ). A more rigorous solution may start by committing leaf nodes and walking back to the root.

I also mention the potential for git hooks to address the issue, but it's worth noting git hooks are not automatically cloned.
So those solutions will require an additional post-install step/script.

Edit .meta Spec:

1. Add New Property:

   • New Plugin (or fork meta-git) that saves commit hashes to .meta under some new key and checks them out on checkout.
   • alternatively, precommit & post-checkout hooks

2. Repo URLs w/ Commit Hash:

   • Fork meta, meta-git, meta-project, meta-init plugins and add support for commit hash on the .meta file project links

Hack Solutions:

1. Commit Message Documentation:

   • There are 2 ways to do this:
     1. A plugin for a commit command that adds hashes of sub-repos to the commit message.
     2. Use a git lifecycle hook (applypatch-msg) to edit commit messages as mentioned above.
   • Then requires some custom plugin, hook, or other solution to retrieve this info at checkout to get the correct commits.
   • Because we are not updating a file, we must utilize --allow-empty on commit.

2. Datetime Checkout:

   • upon checkout, get date of commit. Then for each sub-repo, check out the first commit before that time.
   • Assumes temporal proximity represents the commit state.
   • Out of order commits could cause issues.
   • Top level repo must always be committed last

3. Abuse Tagging:

   • Tag all repos with the same value per commit
   • Pollutes the tagging namespace, additional step per commit.
   • Doesn't make sense for repo reuse as checkout state is only relevant to parents, so storing those tag states across child repos is a poor hack.