4 ms·

I think it depends a lot on what your git repository is. If it's specifically source code for anything that's intended to run, then avoiding including the outp

I think it depends a lot on what your git repository is. If it's specifically source code for anything that's intended to run, then avoiding including the outputs is a smart move. But then, if that's the case, there's a good chance you'd just be committing a .py file. I like notebooks because they include output alongisde input. For example, Peter Norvig's Pytudes are all brilliant, quick notebooks that solve a particular puzzle[0]. The code itself might not be that interesting to run (unless you really want to confirm his strategy for wordle checks out) but reading through the notebooks makes for a great experience of simultaneously understanding his thought process, and seeing the solution. I do a bunch of generative art stuff and have recently been experimenting with using notebooks as quick sketches[1]. I really like the workflow and end up with something like a journal that isn't necessarily intended to be ran repeatedly, but read over, where I can see the visual output created, as well as the method for it. [0] Norvig's extremely cool pytudes, wordle example: https://github.com/norvig/pytudes/blob/main/ipynb/Wordle.ipynb https://github.com/norvig/pytudes/blob/main/ipynb/Wordle.ipy... [1] My not anywhere near as cool as Norvig's pytudes example: https://github.com/benrutter/jupyter-sketches https://github.com/benrutter/jupyter-sketches

WCSTombs 3y ago
You don't lose the outputs, they just aren't committed into Git. So for each new clone, you'd need to regenerate the outputs, but on a single clone, the outputs exist and are persistent in the .ipynb form of the notebook (which is not committed). You are correct that the .py version of the notebook is exactly what Git ends up tracking, with the .ipynb being essentially a build product. (Note that the jupytext paradigm does assume that the outputs can always be recomputed as a function of the inputs. I consider that a best practice, but some might disagree.)

WCSTombs 3y ago

You don't lose the outputs, they just aren't committed into Git. So for each new clone, you'd need to regenerate the outputs, but on a single clone, the outputs exist and are persistent in the .ipynb form of the notebook (which is not committed). You are correct that the .py version of the notebook is exactly what Git ends up tracking, with the .ipynb being essentially a build product. (Note that the jupytext paradigm does assume that the outputs can always be recomputed as a function of the inputs. I consider that a best practice, but some might disagree.)