You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I currently need to merge a lot of branches containing a Pluto notebook and it's a huge pain wasting several hours.
One of the advertising features is "Pluto notebook files are designed to work well with version management.".
I would not subscribe to this statement. Yes, they do work with version management, but not particularly well at the moment.
There are two reasons:
The order of the cells seems to change a lot over time. When merging two versions of a notebook which are 6 months apart, more a less the whole file shows up as one large diff although one version only has a handful of cells added/changed and the rest is some seemingly random resorting done by Pluto over time. But it is nearly impossible with the usual tools to identify this "real" diff.
Whenever you change something during merge, you need to be really cautious to always keep the cell itself in sync with the reference to the cell at the bottom of the document in the Cell order section.
It would be so much simpler if the cells were stored in the .jl file in the "real" order of how they appear in the document. Then, the cell order section could be completely removed if my understanding is correct.
The dependency between the cells can be calculated when reevaluating the document.
Whether a cell is collapsed or expanded can be stored in the cell itself.
The text was updated successfully, but these errors were encountered:
I currently need to merge a lot of branches containing a Pluto notebook and it's a huge pain wasting several hours.
One of the advertising features is "Pluto notebook files are designed to work well with version management.".
I would not subscribe to this statement. Yes, they do work with version management, but not particularly well at the moment.
There are two reasons:
Cell order
section.It would be so much simpler if the cells were stored in the
.jl
file in the "real" order of how they appear in the document. Then, thecell order
section could be completely removed if my understanding is correct.The dependency between the cells can be calculated when reevaluating the document.
Whether a cell is collapsed or expanded can be stored in the cell itself.
The text was updated successfully, but these errors were encountered: