[19:03]<Dantman> Uhm, anyone know how to find a lost commit in git? [19:04]<Dantman> I committed something, then went and reset the master to do something, and ended up making the commit disappear from the logs. [19:05]<Wes-mac> control-Z? :D [19:05]<Dantman> heh, not so helpful [19:08]<Dantman> Is there a way to list commits that are based off of another commit? ie: Based on a commit id, find any commit who's parent is that commit. [19:40]<tlrobinson_> Dantman: you can get a range of commits with git log start..end [20:19]<Dantman> Problem was I didn't know what the id of the end commit was. [20:19]<Dantman> Apparently git 1.6 finally adds --children [20:20]<Dantman> I managed to get my work back since I had not closed gedit yet. [21:05]<Wes-mac> this is better [21:15]<Aristid> Dantman: git reflog can find lost commits [21:17]<Dantman> *sigh* [23:32]<jbrantly> I've just run into an interesting issue. [23:32]<jbrantly> I'm working on my browser-based loader and running against the CommonJS Modules 1.0 unit tests [23:33]<jbrantly> in test.js, the exports.print function tries to reuse an existing implementation: exports.print = typeof print !== "undefined" ? print : function () { [23:33]<jbrantly> which results in it pointing to Firefox's global "print" function for opening the print dialog, and screwing up my unit tests [23:33]<jbrantly> however, I'm wary to modify the unit tests [23:35]<kriskowal> jbrantly [23:35]<kriskowal> oh [23:35]<kriskowal> well, the idea is that there needs to be some way to communicate the results [23:35]<kriskowal> narwhal provides a beyond-spec print method [23:36]<kriskowal> the tests could conceivably be modified to use a module, but there's a bit of a chicken and the egg problem there. [23:36]<kriskowal> you might consider just replacing the window.print for testing purposes [23:37]<jbrantly> yea, I'll probably go that route, but wanted to make sure I wasn't running into some larger issue (like "print" being in-spec)