Skip to content

Latest commit

 

History

History
34 lines (18 loc) · 1.71 KB

4.2-how-do-links-work.md

File metadata and controls

34 lines (18 loc) · 1.71 KB

How do links work?

Links from your project repository to dependencies are committed in two pieces:

The version name, the local path to checkout to, and the remote path to fetch the dependency from are all committed to a file called .gitmodules. This file is human readable and uses the same config format as most other git configuration files.

The precise hash of the commit in the git repo containing the dependencies is stored as a "gitlink" -- this isn't a file you can see with ls, it's part of git's internal tree data structures. You'll see this hash in commands like git show and git diff when a dependency has been added or changed. (You can also see it with git ls-tree HEAD lib/{depname}, if you're curious.)

This will sound very familiar if you've used git submodules before, because that's exactly what it is. :) The only thing mdm is really doing here is intelligently limiting how many commits it fetches based on extra config we added to the .gitmodules file.

Link agreement

TODO version name and hash are two different ways to specify a dependency... and they should refer to the same thing! so, one should never change without the other.

Moving links

Usually you'll only touch either of these components of the link via the mdm command. However it can be useful to understand how they work and how to commit them, particularly when resolving merge conflicts.

TODO well that's barely even true, you use mdm-update in the merge workflow and then chill out

Unsatisfiable links

TODO everyone here is consenting adults and breaking an upstream so that a commit is missing is exactly as much of a cardinal sin as rewriting already-public git history. it's also exactly as doable.