I would think someone trying to view a private file is aware that they are signing in via Github to share it. Github Oauth also explicitly states that code access is shared. So, I don't think it detracts from pomber's project.
The privacy implication of handing over access to private code repos to a complete stranger is real, and this project should warn users that this is what they are doing, front and center.
This project could (and arguably should) have been built in such a way that it didn't require you to hand over read access to your private code repos. It could have been built as a browser addon or greasemonkey plugin.
"I would think someone trying to view a private file is aware that they are signing in via Github to share it." - I don't agree. That is why I wrote my comment. I think lots of people would not even consider the implications of what they are doing.
One suggestion: The long horizontal sliding animation seriously detracts from the user experience. It makes it difficult to track what changed because areas of the code go briefly blank while the next bit of code is sliding in.
Would be a lot less difficult to track changes if new lines of code simply faded in in-place and pushed code around them up and down.
If you want a similar tool built into Atom, check out this great plugin: https://atom.io/packages/git-time-machine
A few years ago I also worked on a similar tool, except it was based on your undo history and was built into an IDE for a visual language: http://web.eecs.utk.edu/~azh/pubs/Henley2016VLHCC_Yestercode...
Also basic info that every other file browser in the universe shows, like file size.
To actually see what happened I found myself triggering the same animations again and again.
Takes you right down memory lane and really gives you a feel for how your codebase has evolved, and the place of each contributor.
EDIT: at least for emacs, there's https://gitlab.com/pidu/git-timemachine
EDIT2: and a different one for Atom with a nice plot: https://github.com/littlebee/git-time-machine
diff -y <(first_sha1:path/to/file) <(second_sha1:path/to/file)
diff -y <(git show first_sha1:path/to/file) <(git show second_sha1:path/to/file)
* A "blame" column could be turned on at the left, showing output from "git blame".
* When hovering over a line in the blame column, the main window shows the historical version of the file when the commit was born. Commit message appears on the left (even more left).
* When it is clicked, the timeline jumps there.
I understand it would be a lot of work, but it would be a super valuable tool for browsing file history in git.
Would be great if there were studies on this. What is the easiest to interpret: in-line, above/below, side-by-side, other options I don't know exist
If we had the past on the left, and the future on the right, then I'd call it a diff.
A lot of people complaining here about it being difficult to see the diff haven't understood what this is for then. But then, what is it for? Just to look pretty?
Is it to easily find the state of a file at a particular date or commit? But then it'd be hard to do if there were a lot of commits. Would be nice to know what use case the creator had.
Otherwise great idea and I really like the URL-based projects.
The animations are great – but I think you should speed em up a bit. The long ease-out period makes it tough to concentrate on small changes. Will most definitely use this!
For my daily work, one obvious problem is that I can't see exactly what changed between revision n and n+1. That's what really makes diffs + commit messages useful. With the slick animation, I know where it changed but the information on what exactly was modified is lost and with it, most of the reasons why I use git diff at all.
Besides showing blame-type information for each like, you can also press 'p' and 'n' to go to previous or next commits; you can press 'l' to view the commit message for the last commit on the line you're at; you can press 'd' to show the diff for the line you're at.
Also, the page links to the github repo for it...