I think keeping some color coding for the lines that got added / removed (better for the characters added / removed) would be nice (e.g. just an almost transparent background color on the lines / characters like Github does).
Otherwise great idea and I really like the URL-based projects.
Within 30 minutes two people want to give you money to run it on private servers.
The entrepreneurial answer to that is:
Write to sales at githistory.xyz, we’ll figure something out.
If you try to view a file in a private repo, it asks you to "sign in with github", which presumably gives them access to read your code so that they can show you this UI.
If only GitHub could do this themselves instead of falling over if you try to run blame on any reasonably large repository…wait, hold on, it looks like this website does as well. Aww…
Exactly. I have wanted this on github for so long — even the animation is beyond what I'd like, I'd settle just for a 'prev/next' button that takes you from change to change. I'm pretty close to just coding it myself for local use.
This is super-slick. Suggestion, scroll to the (top) changed line before the change animation to reveal changes in large files that happened out of viewport. Nice work
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.
I wonder how many devs out there are going to basically hand over access to their companies property (private code repos) to this random guy by "signing in with github", without even thinking about what they're doing.
I'm a bit sad to see this cynicism at the top of a Show HN thread. This project is a fun way to browse code history and it's done with an interesting visual style. It's also open source.
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.
There was nothing cynical about my comment. So you are sad for no reason.
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.
This project doesn't even appear to have a privacy policy or terms and conditions, of any description, so who knows what they're doing with your source code. They could legitimately clone all the private repos that you give them access to, and keep them for statistical analysis or for personal commercial exploitation. Maybe you created a private repo for a NodeJS project but didn't switch the default license specified by NPM from ISC because nobody else should ever have seen the code. Now you've just given your code to a third party with a license that is functionally equivalent to MIT. They can chuck it up in a public github repo and let whoever wants to, use it.
Not quite as pretty, but here's a bookmarklet that allows you to go back by one commit in the github.com blame view (e.g. https://github.com/babel/babel/blame/master/packages/babel-c...). It basically finds the most recent 'View blame prior to this commit' link and follows it.
Seems the project is MIT licensed and written in JavaScript so presumably somebody could package it up in a browser extension so there are no privacy issues when viewing private repos: https://github.com/pomber/git-history - He does have browser extensions but they just look like they redirect you to the service.
Just the other day I had a coworker freak out when he saw me do this. It baffles me how a professional developer could use git for years and never read the manual.
This still needs performance improvements - on bigger files with longer history the transitions between commits get choppy, it shows only the newest 10 or so commits and doesn't load older ones, e.g. [0] has around 2500 lines and a history of around 200 commits. Usability is horrible for such files.
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!
YMMV - I'd like to see highlighting of what's changed, as it's difficult to track multiple changes with the animations. The old stand-by red and green for diffs could work, with the old content eventually fading out or some such - probably a more elegant want to achieve that but hopefully you get the gist.
I like vc-annotate. (Bound to `C-x v g` out of the box for me.)
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.
79 comments
[ 4.5 ms ] story [ 156 ms ] threadOtherwise great idea and I really like the URL-based projects.
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
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.
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.
This project doesn't even appear to have a privacy policy or terms and conditions, of any description, so who knows what they're doing with your source code. They could legitimately clone all the private repos that you give them access to, and keep them for statistical analysis or for personal commercial exploitation. Maybe you created a private repo for a NodeJS project but didn't switch the default license specified by NPM from ISC because nobody else should ever have seen the code. Now you've just given your code to a third party with a license that is functionally equivalent to MIT. They can chuck it up in a public github repo and let whoever wants to, use it.
javascript:(function(l){l.host.match('github.com') && (l.href = l.origin.replace('.com', '') + '.githistory.xyz' + l.pathname)})(window.location);
javascript:(function(l){l.host.match('github.com') && (l.href = Array.prototype.slice.apply(document.querySelectorAll('.blame-hunk')).map((d) => [new Date(d.querySelector(".blame-commit-date time-ago").getAttribute('datetime')), d.querySelector(".blob-reblame a") && d.querySelector(".blob-reblame a").getAttribute('href')]).sort((a,b) => a[0] < b[0])[0][1])})(window.location);
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...
[0] https://githistory.xyz/godotengine/godot/blob/master/servers...
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!
To actually see what happened I found myself triggering the same animations again and again.
https://news.ycombinator.com/item?id=19106499
https://news.ycombinator.com/item?id=19106328
https://news.ycombinator.com/item?id=19102828
https://news.ycombinator.com/item?id=19100110
https://news.ycombinator.com/item?id=19092802
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.
[0] https://github.com/acaudwell/Gource
Takes you right down memory lane and really gives you a feel for how your codebase has evolved, and the place of each contributor.