<div dir="ltr"><div><div><div><div><div><div><div>Stefan,<br><br></div><div>First off I love that other people are joining the conversion. The more ideas are thrown around the better we all will be!<br></div><div><br></div>
Using git (or version control in general) for branching is an interesting idea. I had/have/am considering it but for historical comparisons, which I view as somewhat conceptually different than alternatives based branching. I.e. I have reimplemented the *same* code, lets run both versions and inspect the differences (or hopefully lack thereof!). This is partially branching, but also partially QA.<br>
<br></div>git is a Good Thing, and seems to be considered the Right Way (tm) of using IPython notebook according to the devs. I don't disagree with this; code belongs in version control and notebooks are code with extra bits attached.<br>
<br></div>That having been said, there is a far cry between git being the place that the devs think notebooks *should* live and not having notebooks in git being <i>unsupported</i>. I would argue building actual application features on git brings us pretty firmly into the latter category.<br>
<br></div>Without wanting to put words in his mouth, Min seems to agree. According to my reading of the autosave IPEP he balked at basing the autosave feature explicitly on git based similar concerns. I feel he made the right choice, but the same reasoning applied in this case would lead to the same result I think (not basing features explicitly on git).<br>
<br></div>He is of course perfectly capable of talking for himself however, so I'll stop (sorry Min!) and simply speak for myself. I think it would be a mistake to move from strongly encouraging users to use git or other version control with their notebooks to actually basing major features* of the application directly on the assumption that the notebook lives in git with a specific set of tags/branches/whatever that IPython is going to programmatically interpret in a certain way.<br>
<br></div>*Note this is different than things like a "check in my changes" button if a notebook can tell it is version controlled somehow. At least in my opinion.<br><br></div>~G<br><div><div><br></div></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 9:23 AM, Brian Granger <span dir="ltr"><<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nice idea - some of the branching could be built using git...<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Jul 10, 2013 at 1:40 AM, Stéfan van der Walt <<a href="mailto:stefan@sun.ac.za">stefan@sun.ac.za</a>> wrote:<br>
><br>
> On 10 Jul 2013 04:33, "Brian Granger" <<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>> wrote:<br>
>> It would be nice to write a long notebook and then add metadata to the<br>
>> notebook that indicates that some variables are to be treated as<br>
>> "templated" variables.  Then we would create tools that would enable a<br>
>> user to run a notebook over a range of templates:<br>
>><br>
>> for x in xvars:<br>
>>   for y in yvars:<br>
>>     for algo in myalgos<br>
>>     run_notebook('MyCoolCode', x, y, algo)<br>
><br>
> I think it would be feasible to build git-like cell revision tracking on top<br>
> of the linear notebook, especially once widgets are in place. Imagine a<br>
> per-cell and per-notebook check-in that allows you to swap out different<br>
> versions of a cell, or different notebook configurations. This can be done<br>
> with a very lightweight abstraction that does not interfere with the<br>
> underlying notebook structure at all (in fact, I'd just use git as the<br>
> actual backend, and then have a layer on top that knows how to pick out<br>
> tagged cells from a nb).<br>
><br>
> Stéfan<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> IPython-dev mailing list<br>
> <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
<a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Gabriel Becker<br>Graduate Student<br>Statistics Department<br>University of California, Davis<br>
</div>