Git is awesome. I still learn new things about it every week or so, and continue to be pleasantly surprised.
One of the big lessons at Djangy was how much sense it makes to use git to move collections of files around. Adding other machines as remotes and executing git push is conceptually easier and simpler than trying to remember hostnames and credentials and which files you care about. You do all that setup at the beginning, when you initialize your repository, and then you can always do a git push whenever you want to move files again. It’s fantastic.
This is obviously not the reason git was created. It’s a version control system — these niceties are just added value. Would it be possible to create a new tool that has all the conveniences of this paradigm without all the cruft of a version control system?
The reason this works so well is because a repository is a collection of files (and their versions). We can safely discard the idea of versions for now, which we could accomplish by having a config file in the root of our “repository”. Or, more explicitly, we could define a file that merely references all the files or directories we care about. Then, similarly, we have remotes and credentials specified in that file.
I might try to write this. It wouldn’t care about whether or not I’m using a working copy, or if I have any uncommitted changes, or any of that. I would just be required to add or remove files from my repository and push them.
Hmmm. Does it make sense to “pull” in a system like this? It might. But it wouldn’t do merges, it would just pick the copy of the file with a later timestamp, or more simply, just overwrite everything.
This system could be built the same way git is built; in fact, it might make sense to fork the git project and build it from that.
I have no idea if this actually solves any problems or if it offers and performance advantages. It’s definitely simpler. Perhaps nobody would use such a system. But it might be fun to build.