Hi Renku Team
If a environment with uncommited changes is stopped, renku creates a auto-save branch. However, this branches do not show up in the drop down for new environments or as merge suggestions. Can we adjust this configuration somewhere?
Of course we could always use gitlab to lookup the branches and rename them…
Hello Christen,
The autosaved branches do not show up on purpose in the drop-down menu.
The content will be automatically restored once you start an environment from the same branch/commit combination.
You can find more about the autosave feature in our documentation. https://renga.readthedocs.io/en/latest/user/interactive_stopping_and_saving.html?highlight=autosave#autosave-in-interactive-environments
P.S. We have already tried the solution you suggest, but most people were confused by the unexpected branches showing up when starting a new environment and they claimed it was difficult to guess what was added in the autosave branch.
In the current simplified solution, we try to keep the normal flow and we inform the user about the autosave content being added through a popup. The user can check the differences and decide whether to keep the changes or not once working in the environment.
Just to add to what Lorenzo said: we realize that the current situation can be confusing, but our attempts to improve it made it worse.
If we did something like show you your own (and only your own) autosave branches in the Collaboration tab, giving you an option to create a merge request, would that alleviate the problem for you? With this, we could inform you of this possibility if we detect and autosave branch when you try to launch an environment,
afaik we also don’t currently indicate which commits have auto-save information (@lorenzo please correct me if I’m wrong) - that would probably also be a nice improvement. Because right now you have to start from the commit that you started the auto-saved session from in order to recover the information. And if someone pushes commits in the meantime it’s hard to remember which commit exactly that was.
I agree we currently give poor feedback to the user about existing autosave branches and the UX turns out to be unintuitive.
Here is my proposal to improve it https://github.com/SwissDataScienceCenter/renku-ui/issues/1113
Thank you @rchris for your feedback! Please feel free to comment either in the GitHub issue or here in the thread.
Thank you very much for the detailed response.
The documentation says:
Restore unsaved work
The next time you start a new interactive environment from the same branch/commit combination, you will be notified
I was not aware of this notification. Is this new? We did not see that before. That already improves the transparency for the user about the processes in the background.
We have already tried the solution you suggest, but most people were confused by the unexpected branches showing up when starting a new environment and they claimed it was difficult to guess what was added in the autosave branch.
That’s unfortunate. I can see the challenge to be both, simply and comprehensible.
and we inform the user about the autosave content being added through a popup. The user can check the differences and decide whether to keep the changes or not once working in the environment.
I don’t see that popup, when I connect to an environment that was build from an autosave-branch.
I think this would be sufficient for our users. How can I activate this popup?
Thx a lot
but our attempts to improve it made it worse.
Ya, I can understand that this can be challenging. Very different technical knowledge among the users and subsequently, very different needs. 
If we did something like show you your own (and only your own) autosave branches in the Collaboration tab, giving you an option to create a merge request, would that alleviate the problem for you?
I think that would be a help for our user, yes. Maybe the UI can offer the create a merge request or to discard the existing changes (meaning, to delete the autosave branch).
With this, we could inform you of this possibility if we detect and autosave branch when you try to launch an environment,
I think that’s a good suggestion. That’d make the process more transparent.
Thanks a lot for your ideas and suggestions.
- that would probably also be a nice improvement. Because right now you have to start from the commit that you started the auto-saved session from in order to recover the information. And if someone pushes commits in the meantime it’s hard to remember which commit exactly that was.
I fully agree, yes. Thx.
lease feel free to comment either in the GitHub issue or here in the thread.
Sweet. I will continue directly in the issue, if needed. thx.
There is no need to activate it. It is automatically shown when you launch an interactive environment against a branch/commit that contains autosave information.
The biggest UX problem here is that it is not easy to find out if a branch/commit combination has autosave information.
@lorenzo and all, now that I’m already in here I can just as well chime in on this issue: please don’t make those dialogues any more obnoxious or numerous: due to the way jupyter notebooks work (saving execution count and the like in the notebook itself) we see a continuous stream of autosaves that are just someone running a cell twice (or not running all cells after a kernel restart). Not sure if there is a solution to that; maybe a “danger zone here” setting that would allow us to automatically restart the kernel before/on closing an environment
cheers
@a_user it’s always good to get more feedback, please keep the flow going!
The discussion went on in GitHub, we have already done a couple of changes (link) that will reach RenkuLab soon, and others are being discussed (link).
The general idea is to:
Our current solution works at the Kubernetes pod level only. The actions performed in the Jupyter notebooks may determine a higher than expected amount of autosaves, but the reason depends very much on the user actions.
I hope the future changes will simplify handling the autosaves in your scenario. We considered other less invasive options, but they turned out to be confusing (e.g. restore unsaved work without feedback, or avoid any automatic operation and provide a different branch).
Please feel free to suggest further changes/improvements here or directly in the GitHub issue.
