Let’s talk about Observable Suggestions

Looks like it was actually a cell comment that I accidentally resolved. (It had code in it.)

Hello @curran! The suggestion logic is modeled after Git, but it’s not an exact copy. The workflow that you suggest is correct with the caveat that Person A would need to review the changes before each merge. When reviewing the suggestion from Person C, Person A would see that the suggestion would delete the new content from Person B. They can choose whether or not to accept those changes. When two notebooks are compared, they’re compared in their current state, so Person A would be able to make a decision on every diff, not just the diffs from when the original suggestion was created.

But why would that suggestion delete the new content from Person B in the first place? Wouldn’t the desired behavior be to automatically include the changes from Person B, like Git Pull Requests do?

Ideally, when looking at the Person C suggestion, Person A wouldn’t see a bunch of deletions. Git is smart in the way that it presents a diff where it will try to “patch” the target branch with changes from the merging branch. In this case, changes that took place on main since the fork occurred wouldn’t be present in the diff (unless there’s a conflict). That’s not how Observable works currently. The comparison tool will compare two notebooks using their states at the time when the comparison is viewed. So, changes made to either notebook after the suggestion is created will show up in the comparison if it is viewed after the new changes were made. I agree that it would be helpful if it more closely followed Git in this regard.

Exactly.

Indeed.

Cool! Thank you for taking the time to write up your thoughts and clarify what the current behavior is. I think we’re totally aligned on what the desired behavior is. I’m looking forward to tracking this thread for any future updates in the way suggestions work. I know it’s an extremely complex problem space and it would take some serious effort to get it right.

Here’s a crazy idea for how to implement it: delegate it to Git. Like literally write some server side code that converts a notebook to a collection of files on disk, one file for each cell using the cell id as the file name, then execute the Git shell commands that create two branches and merge them together (or use libgit2 to avoid the overhead of shell execution). Then use the output from that as the input to the current suggestion UI. It would be a lot of work and would add complexity to the backend, but I think in theory that would work.

1 Like