Fintan Halpenny

We have this [PR](https://github.com/radicle-dev/radicle-link/pull/540) for locking around concurrent replication, so hopefully that should fix it

So just to contextualise where this thought came from when I added `ReplicateResult` it bubbled up to this point https://github.com/radicle-dev/radicle-link/commit/087a1bf48f5b5802878c42986b874fff7cf9b4c0#diff-b650ce3d62e812ad5579e43d0805c510f7324e38f24762a9a81f5466b760993bR546-R548. This prompted me to think about whether being `Behind` could...

Makes sense :+1: So I would say the scope of this issue is adding the check for determining if the local is `Ahead` instead then.

I think that the clippy warning can be overkill because one just ends up writing documentation that "does what it says on the tin". The public-facing documentation is there (or...

Something I missed here is how this will inform `radicle-upstream` moving forward. The crux is that we're going to do away with any of the upstream-specific Rust code and have...

> And that’s a problem because? Sorry, ya I should have mentioned. If we fetch a fresh project, we currently _must_ ensure that the `rad/id` exists at the top-level. The...

> Can we not use the `identities` module instead of the (public API) `git::identities`? You can pass the `lookup` function to find the tips (remember resolvers :D) Ahaha sure :)...

> What's "rad_delegate for the project"? Le [rad_delegate](https://github.com/radicle-dev/radicle-link/blob/master/librad/src/git/types/reference.rs#L219-L226) function

Note that the `head` is only used to check that we already have it. We fetch regardless is it doesn't exist. Could it be that if we track offline that...

> The handbook should point out that even numbers of trust delegations are not a good idea. Your friend should always bring one friend with them.