I’ve noticed that when working on some large notebooks I sometimes break smaller sub notebooks off during refactoring.
I also sometimes take my own notebooks, fork them, and spinn them off into completely different directions.
It would be really nice if I could remove the fork information, because to me it implies some sort of logical inheritance, which is confusing to people reading my notebooks.
I think it should be limited to your own notebooks maybe so that work from others is still attributed.
Or maybe just have a “dublicate notebook” option in the notebook list, in addition to the “fork” one.
You can already copy a notebook without creating a fork, because any two notebooks can be merged. The steps are not intuitive, so bear with me:
Open the notebook that you want to copy. This is the ORIGINAL. Access the notebook ID:
for private or shared notebooks: The part in the URL after “/d/”.
for published notebooks: Access the notebook history; the ID is the part of the URL between “/d/” and “@”.
Create a new notebook, save the first cell. This is the COPY.
Open the URL https://observablehq.com/compare/COPY...ORIGINAL, replacing COPY and ORIGINAL with their respective notebook IDs.
Hit the Merge button in the upper right, confirm, and you’re done.
Note: Observable calls the notebook from which we merge the target. I don’t know why, don’t let yourself be irritated by that. This is what you’ll want:
Nice Hack!
But so close, yet so far, as the notebooks are already published, their URL is already burned
So it’s either the annoying fork, or the annoying notebook/2 thing.
I find the reasoning behind all of this pseudo persistence to be really lacking.
If they don’t want to have you unpublish code that other people rely on, they should reference things by hash (content), instead of by URL (location), otherwise stuff might break at any time anyways. Also there is nothing stopping you from deleting your notebook, or just emptying it out, so it’s definitely not a solution to the problem they perceive.
I’m not following. You can give the new notebook (and any fork) any unused URL you like. The slug (URL version of the notebook title) is generated from the first <h1> that Observable finds in your notebook the moment you publish it.
Afaik they’re already working on that (notebooks staying accessible, automatic version pinning).
Thanks! I only thought of it because I stumbled across @mbostock’s comment wrt merging arbitrary notebooks.
Tbh I don’t see how they could implement this in any meaningfully legal way.
They don’t own the licence to the stuff uploaded, so if you change your mind and unpublished it, it has to go.
We need these rights for both public and private notebooks because these rights are necessary for providing the Service.
This license does not grant Observable the right to sell Your Content or otherwise distribute or use it outside of our provision of the Service.
When you publish a notebook, you grant each User of Observable a nonexclusive, worldwide license to use, display, and perform Your Content through the Observable Service and to reproduce Your Content solely on Observable as permitted through Observable’s functionality (for example, through forking).
To the extent this agreement is not enforceable by applicable law, you grant Observable the rights we need to use Your Content without attribution and to make reasonable adaptations of Your Content as necessary to render the Website and provide the Service.
This stuff is specific and limited enough that I don’t see it extend to the point that they can still keep it published after you’ve changed your mind about releasing it.
There’s definitely laws in Germany that allow an author to change their mind and redact their work.
Even GDPR alone should completely safeguard you from this.
The GDPR covers personal data, i.e., personally identifiable information. I’m fairly certain that it doesn’t cover copyright. Be that as it may, let’s not derail the discussion further. Should this feature require changing the terms, then you’ll surely have the opportunity to either agree to the changes or cancel your account.
Yes, there’s nothing preventing you from deleting your notebook whenever you like. The license grant to other users in the terms of service simply means that by publishing, you’re allowing other users to make copies of your published content, say by forking or importing. When you delete your notebook, you’re deleting only your own notebook, not copies other users may have made.
On the original topic, we know there are many different reasons why people fork; sometimes a fork is closely related to its parent while other times it diverges and becomes wholly unrelated. Thus the fork indicator does not imply content equivalence or similarity; only that at some point, the current notebook originated from the parent. It’s merely a historical artifact, if you will.
The fork indicator would be more valuable as a meaningful signal, so we’re considering ways for authors to better express relationships between notebooks. For example, we might allow hiding the fork relationship (for when the notebooks are unrelated) and grouping forks into “branches” (for when forks by the same author are closely related). If you have thoughts on what would work well for you, we’d love input!
Thanks for your clarifications and thoughts
For my use-case, simply being able to hide the fork relationship would be completely sufficient.
If you want to hear my dream solution, I’d be simply git.
I understand that you want to make the interface simple enough to use even without an extensive software development background, but it would be really useful to have both a simple abstracted interface for the common user, as well as a git endpoint for experienced devs.
Even though it might be technically more challenging, I believe that the rewards would be well worth it. It’s familiar to most people, and allows for the straightforward resolution of even the most complex operations, like merging, splitting and rebasing notebooks.
I’d certainly help my workflow if I could simply pull the entire notebook, work on it in the train via vim, and then when I’m home, push the entire thing back. I could even envision hybrid repositories, when pushed to gitlab it’s just a regular old repository with a npm library, but when pushed to observable it becomes this beautiful living documentation. I’d for sure document most of my projects this way, and I know others that’d do too, so it might even be a way to get free advertisement and expand your user-base. I think there’s also a few academics that would consider Observable more for paper like works if it felt more of a platform, than like a service.
It could also solve a number of unrelated problems. Recently bundle.run, has been somewhat unstable repeatedly breaking notebook dependencies for me. Downloading the notebook as a git repo could also allow for pushing prebuilt js dependencies into the notebook. It could also be used to upload notebook specific datasets.
Ofc then repo storage becomes a consideration, but I’d be totally happy if the free user tier was limited to a few mb, with the paid tier opening up more storage. Or maybe the paid tier would be needed to enable the git feature completely, I’d be happy to pay for such a thing
I am also interested in more git-like functionality (why recreate the wheel with suggestions, etc? though these are prob. large/involved changes). But one very easy win would be github-style PRs/Suggestions without the need to first create a fork.
Feature: Allow users to simply make a change to a public notebook and create a ‘Suggestion’ directly. This would really lower the bar for new users to easily become involved in the Observable community w’out managing their own notebooks …
But to return to the actual topic: what the original poster asks for is simple and seems to have no downside. Just allow people to remove the reference to the fork’s parent if they so choose - it is actually annoying to continually see the reference to a no-longer-related notebook
One thing that has changed the meaning / reduced the usefulness of the ‘fork’ indicator is the plethora of published forks from new users which do not at all change the original notebook. There are a bunch of these published every day, so when I see ‘fork’ my first impulse is to think of ‘low-effort unchanged clone by someone who doesn’t yet understand the platform’ instead of ‘new notebook which originally sprouted from a different one but has since diverged’. There also seems to be less ‘interesting’ forking of notebooks than I originally expected for the platform a couple years ago.
But I would recommend people not read too much into the fork label. Having a completely different notebook listed as a ‘fork’ seems just fine to me. There is no shame in having your novel notebooks listed as ‘forks’.
