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
Context: students at our university click on a nbgitpuller link whenever a professor communicates that course-content is either added or modified. Often, students made some modifications of their own, which typically causes one or more merge conflict(s). We definitely stand behind the current automatic merging policy, however, it can get tricky when content is modified in the source, but not detected by the students (users) in their JupyterLab environment.
(Our students have their own JupyterLab environment on a JupyterHub)
Currently, we "manually" communicate a change-log to students, i.e., providing them with a list of modified files whenever the source code is updated, so they can rename these files (if necessary) before pulling again, in order to get the latest version.
Proposed change
One option could be to generate a list of files where a conflict occurs, and present that list in a notification after the merge, together with a note on how users could still get the latest versions, and keep their changes (e.g. renaming the associated files from file.py to file_<date>.py)
Alternative options
A setting where the above change can be configured as automatic, default behavior
A git-like way of providing the merge conflict on each conflicting file, together with an option for users to choose between "keep", "override", or "rename".
Who would use this feature?
Students following (relatively new) courses at our university, i.e., course that are under development, and prone to updated content.
The text was updated successfully, but these errors were encountered:
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋
Thank you for opening this, @svbaelen! The current automatic merge policy definitely isn't ideal when both students and instructors are making a lot of changes to the same set of files. However, I think the primary purpose of nbgitpuller is to make merge conflicts go away by making opinionated choices, and I think providing a merge conflict notice is a bit out of scope here. The error messages could definitely be improved, as right now we just output whatever errors git gives us - I've opened #267 to tackle that.
If you can report individual merge failures, I'd love for us to investigate and fix those! I think we haven't done a run of these in a while, and git's behavior might have changed enough that this is causing problems. Do you have some examples we can look at? If you can open an issue with those, that'd be highly appreciated.
Context: students at our university click on a nbgitpuller link whenever a professor communicates that course-content is either added or modified. Often, students made some modifications of their own, which typically causes one or more merge conflict(s). We definitely stand behind the current automatic merging policy, however, it can get tricky when content is modified in the source, but not detected by the students (users) in their JupyterLab environment.
(Our students have their own JupyterLab environment on a JupyterHub)
Currently, we "manually" communicate a change-log to students, i.e., providing them with a list of modified files whenever the source code is updated, so they can rename these files (if necessary) before pulling again, in order to get the latest version.
Proposed change
One option could be to generate a list of files where a conflict occurs, and present that list in a notification after the merge, together with a note on how users could still get the latest versions, and keep their changes (e.g. renaming the associated files from
file.py
tofile_<date>.py
)Alternative options
Who would use this feature?
Students following (relatively new) courses at our university, i.e., course that are under development, and prone to updated content.
The text was updated successfully, but these errors were encountered: