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.
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.
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.
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'.
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.
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.
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.
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 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
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.
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.
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?
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.
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.
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 :)
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?
Plus a slider to see where you are in the timeline would be sweet.
Great idea!