Documentation and fixing minor things
will edit later
This was 50% started in the last devlog but I decided to only write about it here.
I ran into a major issue with the github REST API - rate limits. If your project had 200+ files, then it would run into the rate limit for sure. And while I could’ve let this limit stay and make it easier on myself, I decided that I didn’t want to live within this limit, and it was time to look for a new git solution.
The solution: isomoprhic-git. Its a library that gives FULL git compatibility and features but its written completely in javascript. The only bummer was that it was a git clone, meaning it created a .git folder and operated out of that. I really dont like the idea of having a .git folder shadow a twig user, because then what is the point of someone using my version control, right?
so heres how github pushing/pulling works with twig and isomorphic git.
when you use the github push command, twig creates a folder called “twig-engine” within the “.twig” folder and that twig-engine folder is basically a “.git” folder renamed. Then, twig does its needed treeWrite operations in that twig engine folder, pushes it to github, and then deletes the twig engine folder. Basically, it is never seen by the user and only appears when needed.
this coding session is filled with a lot of small different things. I’ve come back to a lot of features and added touch ups / fixes to things I said I would come back later to. Something important is the main bin.js file, which is now approaching 2000 lines of code, is being split up into multiple files to make it easier to understand and for me to debug/make changes. Another thing is that I’ve started the documentation for twig and its commands / how it works.
for the last 10 hours i’ve been trying to make twig compatible with github. but this is much much much harder than i ever thought it would’ve been.
the git smart http protocol is how git communicates to any service like github/gitlab etc. The problem for me is this protocol has had 20 years of development and improvement and it is extremely difficult to understand let alone recreate. Github only knows this form of communication (packfiles and delta compression) so I have to find a library that can communicate to github.
But it doesn’t get a lot better… there are of course git libraries but none of them are for ONLY uploading / pulling things from github. Furthermore, they are all git clones meaning they operate within a .git folder and they aren’t met to be used as a SDK in another version control client.
So, heres what I went with: the github REST API!
it lets you create commits / trees / blobs and then push them to repositories. So thats exactly what I used
Twig can now merge branches with its own merging algorithm.
This was a really really hard command to get working. It was ALOT of debugging and trial/error but in the end it works really well and im super proud of it.
At the moment, if there is a merge conflict, you have to pick which branch’s changes you want to keep.
So… I kinda forgot to write dev logs because I got extremely carried away with the coding. Once the ideas started coming, I was just adding command after command.
So, i’ve decided to write docs for twig so you can see the list of commands AND in the docs will be a much better explanation of how a version control client works because it is pretty hard to understand.
I’ll use devlogs just to briefly summarize the progress ive made but not describe how things work etc.
- twig can have branches now
- twig can switch between branches with checkout (twig reads the tree for the branches latest commit and automatically adds/deletes/modifies files to match the branches state)
- twig has a really ugly server page it runs with the GUI command so you can view the projects branches then commits then what the files looked like at that commit in time.
login - this is really special. login to my own custom auth server and store a user token. this token will be used to authenticate to my server.
push - push your project files to my server so you can access them anywhere. it stores them successfully but i haven’t gotten the view part down yet.
twig now can handle as many commits as you want, and then read them back to you in order with the history command. on top of that, you can compare two commits using their commit hashes (added, deleted, modified)
something cool about the compare command is that you can input the commit hashes in any order, not which came first, because twig automatically finds which comes first.
Commits now generate a new tree, and that tree captures the current working directory. If someone commits and only changes one file very close to the root folder (not deep inside folders) then only that root tree is going to change, and the rest of the subfolder trees wont.
Also, I am officially renaming this project! I picked chimp because i wanted it to fit the theme with another tool I built that was monkey related. However, it doesnt fit well to me so rename coming soon…
Added commit feature. It takes a message and hashes any new files or any files with changes made. Next session, I need to make it so it also generates a new tree per commit.
chimp now stores the file tree of which hash is which file in a sqllite database!
Wrapped up the initialize command: it now follows through the entire directory, all subfolders and files and hashes them.
next step is to make a tree map that tells you which hash is what file. For that next step, i spent some time messing around with sqllite which is what i will be using to store that tree map.
The goal: build a version control client just like git. Maybe even a custom website to store users code online?
I started with the first command for my “git” clone, which is “init” and then also test hashing + file writing abilities.
The name is “chimp”
80% of doctors calendar done
