
git playback - mmozuras
http://codingfearlessly.com/2012/05/14/git-playback/
======
macrael
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!

~~~
mmozuras
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!

~~~
knowtheory
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 :)

------
vladev
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/>

~~~
caf
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.

~~~
zorbo
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.

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

------
Cherian
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..

~~~
skeletonjelly
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

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

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

~~~
Cherian
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 …. :-)

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

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

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

------
temphn
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.

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

Thanks!

------
WilliamEJDoane
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...](https://github.com/WilDoane/GitDataCollection/blob/master/analysis-
tools/OutputCommits.sh)

------
kenko
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?

~~~
tveita
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.

------
markm208
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>

------
ilaksh
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.

------
daenz
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 :)

~~~
mmozuras
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
:)

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

------
writetoalok
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?

~~~
mmozuras
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>

