Can you default to `execution-count: none` when stripping notebook outputs?

[spd_dat]

When committing to a git folder, IPYNB outputs are usually stripped, unless allowed by an admin setting and toggled by .databricks/commit_outputs. This sets the

{"execution-count": 0, ... }

within the IPYNB metadata. Is there a way to set it instead to

"execution-count": null

? This would align the behavior with nbstripout. Currently, if you use nbstripout as part of pre-commit.ci , the hook is triggered every time a Databricks notebook is committed. (And I'd guess there's no particular advantage of setting it to 0?)

(Admittedly, more of a feature request.)

[mark_ott]

Databricks does not currently allow you to default to "execution_count": null (or "none") when stripping notebook outputs during a commit. The platform sets "execution_count": 0 as the default when outputs are stripped through their Git integration, and there is no exposed configuration, setting, or admin toggle to change this to null.​

This behavior is distinct from the nbstripout tool, which sets it to null, aligning with the Jupyter/IPYNB standard. The inability to change this in Databricks is known (and sometimes raised as a feature request) but remains a limitation of the platform at this time.​

If you need the execution count field to be null, you will need to use a separate stripping tool (such as a post-commit hook using nbstripout or a jq script) outside of Databricks, after the commit operation, to rewrite the field as desired.​

There is no practical advantage in retaining 0 over null for stripped cells; null is more compatible with standard tools and CI policies.​

[spd_dat]

Thanks, but why do I have the hunch that you used an LLM to provide this answer. 

I understand all the points, but as you yourself write:

> There is no practical advantage in retaining 0 over null for stripped cells; null is more compatible with standard tools and CI policies.

Hence the feature request is to change the behavior to the one which is "more compatible with standard tools", given that the current behavior has "no practical advantage".