Git clone a repository from someone else's computer
Your colleague has a git repository on their machine and you want to clone it. The usual way: they push it to GitHub, you clone from GitHub. If the repo is private, they add you as a collaborator, you set up SSH keys, then you clone.
If the repo is not on any remote yet, or if you do not want to push it to a server, there is no obvious way to clone directly from their machine.
You clone straight out of the folder the peer shared
Connect to the other person with KEIBIDROP and enable the virtual folder. Their shared files appear as a directory on your machine. If they shared a git repository, you can clone it like any local path.
Most people know git clone with a GitHub URL, and git can also clone from any folder on your disk that contains a .git directory. Since the virtual folder looks like a normal directory to your operating system, git treats it like a local path.
# Your colleague's files appear as a folder on your machine
$ ls ~/KeibiDrop/Mount/
my-project/ notes.md data.csv
# Clone their repo the same way you would from GitHub, but from the local path
$ git clone ~/KeibiDrop/Mount/my-project ~/projects/my-project
Cloning into '/Users/you/projects/my-project'...
done.
$ cd ~/projects/my-project && git log --oneline -3
a1b2c3d fix: handle edge case in parser
e4f5g6h feat: add CSV export
i7j8k9l refactor: split utils into modulesThe virtual folder at ~/KeibiDrop/Mount/ shows your colleague's shared files. Git reads the repository objects from there. KEIBIDROP streams each object from their machine as git requests it. The clone goes into your local workspace and you have a full copy with all history.
Git never learns that the files are on another machine
The virtual folder presents the peer's files through the operating system's filesystem interface. Git does not know the files are remote. It reads .git/objects, .git/refs, and .git/HEAD like it would from any local directory. Each read request is served by streaming the data from the peer over an encrypted connection.
This suits pair programming and repositories you cannot host
Pair programming sessions where you want to share a working copy. Repositories that are too sensitive to push to a hosted service. Situations where you need to clone a repo that only exists on someone's laptop. Hackathons, workshops, or conferences where setting up SSH access is too slow.
The folder goes both ways, so you can share work back
The virtual folder is bidirectional. If you share a file back, it appears on the peer's side. You can also browse their repo, run the code locally, and pull changes by reconnecting later. For real-time collaborative editing on the same files, use git as the merge layer on your local clones.