suggestion for me to fork the project which is in fact fork of my project

[volodymyrss]

Description

I am given a URL to start a session with a project of @burnout87 , like that

It is suggested that I fork the project, but the project is already a fork of my own project, so I can not even fork it back:

Reproduce

• A creates a project
• B forks a project
• A tries to start a session from the project of B
• A realizes it's better to start from own fork of this project
• interface does not help A to understand that the project is B's fork of A's own project, and fork button leads no good place

Side note

I see the "There is unsaved work from your last session which will be restored" button even after clicking the "delete autosave" here several times. It does not get deleted?..

[lorenzo-cavazzi]

Thank you @volodymyrss , it's an interesting case.
When linking to the "Start with options" page, we could actually check for the user's projects and show an alert when we identify a fork. It's not totally straightforward tho:

• Forks in the user's namespace should be considered, but groups probably discarded.
• I'm skeptical about adopting the same workflow for quickstart links (the one that automatically starts the session) cause alerts are ineffective when users don't need to take actions, and we don't want to require clicks in that case.

We will think about possible solutions.

P.S. We will revisit autosaves soon and that error will go away. It's likely to be a problem with permissions: currently, autosave branches are created automatically by the system in the repository. However, removing them is done from the UI with the user's credentials that might not allow to delete branches in the repository.

[volodymyrss]

* Forks in the user's namespace should be considered, but groups probably discarded.

Yes, this looks tricky since there is potentially a whole set of forked repositories, and I may be able to write in some of them.
So I may want to start a session from one of those, but they might not have the commit I want.
Somehow maybe I would even want to even see here a commit tree, spanning different forks, indicating which forks are writable. But maybe that's just me :)

* I'm skeptical about adopting the same workflow for quickstart links (the one that automatically starts the session) cause alerts are ineffective when users don't need to take actions, and we don't want to require clicks in that case.

Yeah, I understand.

We will think about possible solutions.

P.S. We will revisit autosaves soon and that error will go away. It's likely to be a problem with permissions: currently, autosave branches are created automatically by the system in the repository. However, removing them is done from the UI with the user's credentials that might not allow to delete branches in the repository.

I am not sure I understood how this behaves, do autosaves happen in other user repository, in which I have no rights?

[lorenzo-cavazzi]

[...] I am not sure I understood how this behaves, do autosaves happen in other user repository, in which I have no rights?

Correct. You can give it a look here https://renkulab.io/gitlab/gabriele.barni/grb-detection/-/branches
A system's user with special permissions creates them when needed, but then you are limited by your own user permissions when interacting from the UI.
We should fix this, but we will soon switch to a different approach for autosaves (it won't rely on GitLab branches anymore)

[volodymyrss]

[...] I am not sure I understood how this behaves, do autosaves happen in other user repository, in which I have no rights?

Correct. You can give it a look here https://renkulab.io/gitlab/gabriele.barni/grb-detection/-/branches A system's user with special permissions creates them when needed, but then you are limited by your own user permissions when interacting from the UI. We should fix this, but we will soon switch to a different approach for autosaves (it won't rely on GitLab branches anymore)

Right, thanks for the details! I remember discussions about this but was not sure what is the current status. And anonymous sessions are not saved? Will be saved in the new approach?

[lorenzo-cavazzi]

We still haven't finalized the preliminary plans for the new solution -- it requires pinning down some infrastructural changes. This should happen in a few weeks from now, but other things with higher priority came in so we don't have a specific date yet.

I marked your name in the list of contacts for some early user testing and I'll reach you as soon as we have something more concrete (if that's still ok with you).
We probably won't save anonymous users' sessions, but we will be way more flexible in defining autosaves life, so we could consider keeping them around for a short timespan (30 minutes?) to prevent losing work accidentally

[volodymyrss]

I marked your name in the list of contacts for some early user testing and I'll reach you as soon as we have something more concrete (if that's still ok with you).

I'd appreciate, thanks!

We probably won't save anonymous users' sessions, but we will be way more flexible in defining autosaves life, so we could consider keeping them around for a short timespan (30 minutes?) to prevent losing work accidentally

It could be useful for me as a user to have a very clear indicator that some sessions are temporary, like a big red banner.

Also, even if I start a temporary session, I may want to reconsider and preserve the results after I investigated for a bit. So a simple way to fork repository and push there from within renku session would be very useful for us.