git playback | Hacker News Reader

git playback

codingfearlessly.com

100 pointsmmozuras35 comments

This is a good idea, and something that I think would be interesting beyond seeing just how people solved katas, but I think that it would be much much better if you had the transition between commits happen in place instead of sliding in. The sliding transition makes it so much harder to see what changed, whereas if you just had the visible code change in place instantly, people can jump back and forth between two commits and easily see what has changed. Maybe even give the new code some highlights or something to make it stand out.

Plus a slider to see where you are in the timeline would be sweet.

Great idea!

Good point, fade-in (or something else, I'll probably try a couple of different things) should make a lot easier to see what happened from commit to commit.

Two great suggestions, thanks!

I dropped by the thread to suggest the fade-in as well.

It'd also be super nice if there was a header for each view with the commit message/description :)

I also dropped by to suggest a fade in/out. The slide effect makes it difficult to see what has changed. You could also use colors to hilight the changes.

I actually quite liked the lack of slider because it feels more like it might have felt to go through the exercise at the time.. You're sort of forced to evaluate what state the code is in without knowing how far we are from being 'done'.

I think it would be nice to see commit messages at each stage too, which would be useful if the developer was documenting the purpose of each commit as they went.

This would be a really useful feature. Good commit messages often help me to better understand big changes to something.

Came here to say exactly this. A fade between the two, or blocks of the diff added in-line would be a better transition here. The slide is just too difficult to follow.

Especially considering git is all about changes in content, not files.

This seems like a nice idea, but - this could be just me - my commits are rarely a couple of changed lines. I usually commit on an "entity" basis where I make one class/module/function along with the tests for it and commit.

Maybe a tool like meld[1] (which already supports diff-ing between your working copy and HEAD) gaining this capability to step through commits would be quite useful.

Still good idea, though!

[1]: http://meldmerge.org/

Thanks. that was one of my hopes actually - that someone would see git-playback and think 'wouldn't it be cool if <insert-tool-name-here> could do something like this?'

That's how people usually work with traditional centralised VCS, but with a DVCS like git the "commit early, commit often" strategy is viable. You should try it - create a branch for your new class, commit to it as you go, then when it's done, commit it back as a merge on mainline.

I completely don't see the "commit early, commit often" idiom working. It may be a viable method of deployment, but I honestly fail to see how it would improve commits.

For me, the "atomic commits" strategy is still the way to go. Whether it's early, or often, doesn't matter to me. In that regard, nothing has changed since I've switched to DVCS. I might even go so far as to say, if you've changed commit strategies since switching to DVCS, you weren't using your centralised VCS correctly.

The "branch early, branch often" strategy is an entirely different matter though.

I think fade effect would be better, because it's easier to see what changed.

Perforce has something similar though not exact called Time Lapse View

http://filehost.perforce.com/downloads/media/tlv/tlv.html

I’ve been missing this in git for sometime..

That's really cool. I use their tool p4merge for diffing and merging for TFS (shh) and git and it's awesome. They offer it as a separate download, would be great if they opensourced this :D

I don't think since this is deeply integrated into their SCM. Git playback evolving into a time lapse view would be awesome.

I wonder what their license/patent is on this application, would it be untoward to imitate this style without repercussions?

The way I understand (correct me if I am wrong) is that Perforce’s value add with features like this is what makes it sticky. So from my gut they will have some patents on this.

But that said, I had once used http://code.google.com/p/svn-time-lapse-view/

The experience wasn’t usable at all since there was no caching, prefetching etc. Each move of the slider resulted in a web request.

But git is a different story …. :-)

Not sure I see the advantage over "git log -p [filename]", which includes diff formatting, color coding, and commit log messages.

diff formatting is not the easiest / most humanly parsable format to read.

Neither is source code. Both take practice to master. Both are worthwhile.

This is pretty cool. If you could figure out some nice CSS3 transition effects for the application of a patch diff it would be even cooler. Like lines sliding and other lines moving down. Maybe with a little bubble up that fades in the Gravatar of the person that made the commit as those lines appear or disappear.

This might be more than just a nice to have. Our eyes are a lot better at detecting small motions than they are small differences. So if you are looking at a big file and keep going through the playback like this, a small change at the bottom that might have missed your attention before will now be very obvious.

That would awesome. Have no idea how to do it, but if it's possible, I'll try to figure it out :)

Thanks!

I was working on a similar idea earlier this year, but wanted to see the line changes from one version to the next. See http://dl.dropbox.com/u/1184374/chat-server.js.html and https://github.com/WilDoane/GitDataCollection/blob/master/an...

The describe_string_calculator function (the stuff on the left-hand side of the slides) seems like a pretty bizarre way to describe the spec: all it does is define functions, some of which also define functions, but none of which is ever called, or is even callable, as far as I know (maybe with some black magic). Suppose that custom delimiters didn't work: how would this help you discover that?

The description of the video the example was taken from (http://vimeo.com/8569257) notes that the tests are done using his (Gary Bernhardt) own Mote framework (https://github.com/garybernhardt/mote)

From a quick look, it does indeed use some very black and rather... funky magic to locate and call the inner functions.

Playbacks can be a great way to learn. I believe git does not provide enough data about the programming process. I am creating a version control system where playbacks are first class citizens. With playbacks developers can create stories about how their code evolved.

http://www.storytellersoftware.com

I don't see why a transition effect helps at all. Just switch directly to the next version, I say.

If you are doing a transition, what would be cool would be if it could actually somehow detect individual text moves and deletes and insertions and animate those. Otherwise I don't see a transition as helping.

Really cool. Any chance you would want to use https://github.com/amoffat/pbs in the script? I know how painful writing anything in bash is :)

I considered ruby and python, but decided to write it in bash. It's a little bit harder, but I did not want to have any dependencies on runtimes/frameworks :)

...any runtimes except *nix (or cygwin), that is.

Git playback of git-playback repo gives a blank screen and navigation buttons do not work. Is this because of HTML escaping is missing. Or is the script limited to python src alone?

Maybe it caused a stack overflow :P

Yes, HTML escaping is missing. That'll be one of the first things I'll add. Probably relevant: https://github.com/mmozuras/git-playback/issues/2

Reply on news.ycombinator.com