3 ms·
Can anyone here answer whether it’s normal, when building git based interfaces, to only use the API for queries and contextual things but utilize regular git co
by gt_ 9y ago
Can anyone here answer whether it’s normal, when building git based interfaces, to only use the API for queries and contextual things but utilize regular git commands to perform interactions with the remote repositories?
I am a 3D artist building a system to version control the configuration/script file directory trees for all the applications I use on a day to day basis. I will be taking a look at this code for clues but maybe someone in this thread can help me with some questions.
Does anyone know something similar to this? I am modeling it on the VSCode Setting Sync extension, which is simple but a little rough itself.
I am using Python and just about have what I’m going for but it’s not as tight as I want it to be. I got a good system of using one repository with a branch per directory tree and folder symlinks to organize it locally. I can pull the branches into individual local repos per remote branch and it works nicely. This allows me to use regular git commands when I need to without fussing with other application’s configuration trees.
But things get pretty loose when it comes to building the backup() and restore() functions. For restore(), I can just doing an overwrite with fetch then reset hard —HEAD or various things like this but it seems like there must be a better approach considering the local repository, index etc. are a bit unnecessary. If anyone has any thoughts, links or pointers, I’d be super thankful! Sorry for the long post.
- mschuster91 9y ago> Can anyone here answer whether it’s normal, when building git based interfaces, to only use the API for queries and contextual things but utilize regular git commands to perform interactions with the remote repositories? Because there are a myriad ways to connect to remotes: local filesystem, git protocol (rare), git+ssh, http(s), whatever-git-clone-"user@host:myrepo.git" does, svn-bridge are the ones I know and it's well possible there are more. So you'd need around 4-5 protocol reimplementations, plus some way to configure the weird stuff that people do with SSH (public keys with or without password, ssh-agent, custom ports, port knocking, bastion hosts, whatever else one may fit in .ssh/config)... best leave this to git, especially as there's a lot of crypto in there that you're bound to mess up.