Skip to content
This repository has been archived by the owner on Feb 15, 2022. It is now read-only.

Move to git #2

Open
jyn514 opened this issue Apr 18, 2018 · 12 comments
Open

Move to git #2

jyn514 opened this issue Apr 18, 2018 · 12 comments

Comments

@jyn514
Copy link
Owner

jyn514 commented Apr 18, 2018

Version control is hard. Let's let git do the work for us. This will allow for greater adoption and more features.

Additions

  • add tags on left-hand side of browser
  • add commits somewhere (where?)
  • add basic UI for git: files, directories in current commit
  • add parameters to GET request, something like index.php?tag=v1.1 or ?commit=ba42a521

Deletions

  • snap.sh could be removed altogether
  • snappy.sh could be removed (why is it even here?)
  • upload.php could be removed since front-end only needs to ask for git directory
  • zipfiles and zip could be removed

Backend

I would like this to be as dynamic as possible, i.e. highlighting and html are not created until requested. Ideally the speed would be dependent only on git and pygments, both of which are pretty fast.

Summary

Use a cache dir, preferably ~/.cache/snap.
Given either commit or tag, create a subdirectory in cache with that name
(we'll assume for this project that rewriting history won't happen because that will be a nightmare).
Checkout the requested file from git and run it through pygments.
Provide the HTML back to the browser.

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

Note that we want the git dir and the cache to always be in sync with respect to the git repo. The easy way to do this is to put a file named .git in the cache with the contents gitdir: <path>/.git. git will do the rest automatically as long as our pwd is the cache.

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

For showing files in the front-end, we probably want to use git ls-tree <commit>, which is pretty easy to parse.

Example:

$ git ls-tree HEAD   
040000 tree 563c2e702ac939bb9cfcf057176de696c93736de    .backupzips
100755 blob 538ae1aee462aa0fa410b24c3b239119a96e4480    README.md
040000 tree 0cacbd8b68588cdfcffeeca5a709307fe189f758    debugging
100755 blob 631bc92ffa57bc202c1dac78d96bbeaea624571e    highlights.css
100755 blob e46a5f76432646f1c22d0f9c1285440fb273d7d3    index.php
100755 blob 3e73212c161e672641ad4722f433aacb887fc5bf    main.css
100755 blob 69b6f86b133d40a9a278a2cb0b74df408e06a808    snap.sh
100644 blob 2620505f6eb3fb23536673f14281108f0abddf56    snapper.png
100755 blob f134c935bca0fb0cf142c733b669d2ca285c3230    snapper.py
100755 blob 102bcbaa9b595da6cba9e0ce9c411f5b8c6cba12    snappy.sh
100755 blob 8e24b2a3aeca44b23a96e2864f7a956447499819    upload.php

Note that unlike ls, we have to use a trailing / to show the contents of a directory:

% git ls-tree HEAD debugging 
040000 tree 0cacbd8b68588cdfcffeeca5a709307fe189f758    debugging
% git ls-tree HEAD debugging/
100755 blob 8a1218a1024a212bb3db30becd860315f9f3ac52    debugging/a.txt
100755 blob cbada099ccf812d154bffb6231e9ef48f139ee53    debugging/b.txt
100755 blob 70927a9218c76bcf7291c9f01b78e638f2c411d2    debugging/c.html
100755 blob 70927a9218c76bcf7291c9f01b78e638f2c411d2    debugging/c.html.old
040000 tree 7aab72fbacfaf546d5b073286a1f2565daf9b6b6    debugging/cppsnap
040000 tree 0e894e4d115e247e94b9deac3be864628e411096    debugging/testsnap

We could do git ls-tree --name-only, but then we wouldn't know what's a file and what's a directory.

Example:

$ git ls-tree --name-only HEAD     
.backupzips
README.md
debugging
highlights.css
index.php
main.css
snap.sh
snapper.png
snapper.py
snappy.sh
upload.php

@jyn514 jyn514 changed the title Move away from zip files Move to git Apr 18, 2018
@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

We should probably use subdirectories for each commit so it's easier to cache the HTML. git show-refs will work for tags, we'll have to use git show-refs --head HEAD for head :/

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

@Brenn10 do you want me to append '.html' to the end of the files? Since you'll have the original filename already, I think it'll make more sense just to use that.

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

This is mostly done on the backend. The script requires the arguments directory, commit, and optionally multiple file. The results are placed in ~/.cache/snap/<directory>/<commit>/<file> as highlighted HTML. It all needs more testing but it works at least locally.

On the front end we need the following @Brenn10 :

  • a browser for the files in a directory. I can provide you with a directory listing from the backend if you need. It will be fairly similar to how you look at directories in the zipfile currently
  • a button for commit and files. This means we can take out most of the current buttons.
  • memory of which file we've been tracking. I don't think from looking at index.php that this has been implemented, but I might be wrong.

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

oh btw hunter I put all the diffs in file.diff, I thought that would be easiest so we don't have to reimplement code highlighting. See #7

@Brenn10
Copy link
Collaborator

Brenn10 commented Apr 18, 2018

no need to put extensions, i can assume

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

I realized when writing this that some of the files will be binary, e.g. snappy.png can't be turned into html. How should I indicate that?

@Brenn10
Copy link
Collaborator

Brenn10 commented Apr 18, 2018 via email

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

To make it easier for you I can put a .html anything that's been highlighted and leave anything that needs to be blank as the original.

@jyn514
Copy link
Owner Author

jyn514 commented Apr 18, 2018

We could also run file on anything in snaps to find the filetype

@jyn514
Copy link
Owner Author

jyn514 commented Apr 19, 2018

Just showed this to Hunter - git log --graph --oneline is beautiful, I've made it an alias. Hunter thinks git log --oneline --parents would be to parse, which is probably true. (this is what we'd use for the UI)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants