Use nbdime as default diff tool for Jupyter Notebook on Github

[odysseus0]

I know that this is not really an issue but I feel that this is probably still the best place to voice it. As we all know now, nbdime is the best diff tool out there when doing version control on Jupyter Notebook. As a matter of fact, the generic diff really does not work with Jupyter Notebook. So is there any way for us to use nbdime when viewing notebook file change in Github? If not, how could we voice our opinions to Github so that they might consider it?

[odysseus0]

I just opened a post on Github Community Forum to request using nbdime as the default diff tool when working with Jupyter Notebook. Please support it if you want to make it a reality soon.

Here is the link: https://github.community/t5/GitHub-API-Development-and/Use-nbdime-as-diff-tool-for-Jupyter-Notebook/m-p/18725#M858

[vidartf]

Thanks. There is an existing issue on this here: #243

There has been some pushes for this in the past, where some people from github has expressed interest in getting this to work. However, it has been hard to get an answer from github on whether they can use nbdime as it is now, or if there would need to be some changes (and if so, which changes).

[odysseus0]

Thank you, @vidartf. The issue you referenced was already years-old and it seems that there has been no progress announced at all. Not sure how to get Github or Microsoft's attention.

[neovintage]

👋 @odysseus0 @vidartf

I work at GitHub. I'm super interested in making the diff / merge experience better. Would love to collaborate on this!

[vidartf]

@neovintage Cool! What would be a good place to start? We could do a call (anyone else willing to contribute time to working on this would ideally be welcome to join as well) to get on the same page about what would be needed ?

[neovintage]

@vidartf getting a call set up would be a good first step. That'll help me understand the state of the project, future goals and where support is needed. email me at my github handle [at] github.com and we can go from there.

[supervanya]

@neovintage any update on this or did you end up not doing a call?

[odysseus0]

Damn. This issue is almost one year ago. I am getting back onto it and will email the dude.

[odysseus0]

@neovintage Let's set up a call.

[vidartf]

Note @neovintage and me did originally have a call, but I didn't hear anything after.

[neovintage]

Hey everyone!

We're still looking into this. There's a bit of technical work we have to do on the infrastructure before we can pick this up. I'm not sure how long that's going to last but when we're ready, we'll start to pick this up again and I'll reach out. 😄

In the meantime, if anyone has interesting workflows with jupyter and git that they'd like to provide feedback on, please feel free to reach out to me.

[hamelsmu]

@odysseus0 @vidartf just following up on this for transparency, I had reached out to @vidartf on email and he responded with some questions for us that we will need to research.

Will ping this thread again when we have some answers, or if appropriate I'll move that conversation from email to this issue for greater transparency. Some questions/comments posed by @vidartf to us:

Note that the current way nbdime works is by default for diffing uses some dynamic content based on user interaction, notably on how to render outputs:
- Which mimetype in the "mime bundle" should it render?
- Should it render it or show the source diff (e.g. if the output is HTML)?
This logic would be hard to translate for a truly static HTML output, so some opinionated choice would have to be made.

cc: @awmatheson @T-Holland @inc0

[pierreguilmin]

Hey everyone! Do we have any news on this? I would love to see this feature coming soon to GitHub.

[hamelsmu]

@arfon is the one who can comment on the progress (or lack thereof) here

[hamelsmu]

I would really love to see this feature come to GitHub, too.