Make git diff prettier

[craffel]

Involves making a custom difftool

[craffel]

Depends on #46

[nkandpa2]

Took a first cut at this. Here's a sample for some feedback:

@craffel I think you said this depends on #46 because we want the diff tool to give some idea of what intermediate changes were applied between two versions of a checkpoint (e.g., between commit A and commit B there were 2 sparse updates and one dense update). As per my current understanding this will not be possible with the information that git provides external diff tools. The interface git enforces for diff tools is that they take the following parameters: diff-tool path old-file old-hash old-mode new-file new-hash new-mode. Since there's no information about what commit the two versions come from, we won't be able to display the intermediate changes applied.

[blester125]

I think with the way I setup the parameter updates on the FS we can actually figure out the updates applied.

Basically each update to a parameter is stored in a sub-dir that is named with the hash of the parameters for that update. So if we follow to metadata backpointers from .../params/updates/${new-file["${param_name}"]["hash"]} (or the parameter metadata file which I think has dup information rn) until we hit old-file["${param_name}"]["hash"] we should be able to tell what updates were applied.

I think this is dependent on the diff direction through? Like we need the on-disk .git_theta/... dir to be the one for the most recent model. If the on-disk value is older commit we can't do this.

A demo FS dir can be found here https://github.com/r-three/git-theta/blob/3e8566a83b6ef1e5cc5a24dc41ad7e0d73b8a0d3/git_theta/updates/base.py

[nkandpa2]

Yeah, just took a look at the updates PR and this seems feasible for diff-ing versions that do not have a dense update between them (since the updates folder is purged upon a dense update). I guess I'll wait on implementing this feature until after #92 gets merged.

[blester125]

Finished in #207