From d657ac3ca7028a3bdfff7994d4f1e07282ce2d38 Mon Sep 17 00:00:00 2001 From: jasongfleischer Date: Fri, 4 Apr 2025 00:17:14 +0000 Subject: [PATCH 01/12] updated plot title on main --- Project.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Project.ipynb b/Project.ipynb index aae8945..1cfd3b3 100644 --- a/Project.ipynb +++ b/Project.ipynb @@ -26,7 +26,7 @@ "ax.plot(t, s)\n", "\n", "ax.set(xlabel='time (s)', ylabel='voltage (mV)',\n", - " title='About as simple as it gets, folks')\n", + " title='The simplest plot in the world')\n", "ax.grid()" ] } From 87dea24e69e0d0c86efaf4e1e1bd4bf645f66d63 Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Thu, 3 Apr 2025 22:00:31 -0700 Subject: [PATCH 02/12] Update directions for the exercise --- README.md | 50 ++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 36 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 1d8cc0c..d7633df 100644 --- a/README.md +++ b/README.md @@ -1,16 +1,38 @@ # GitExercise_Conflicts -1. Clone this repo to your datahub or local computer (your choice) -1. Merging ex1 branch into main branch... the difference here is a simple line of text conflict\\ - 1. first look at the diff - 1. now merge e1 into main; note how the conflict gets shown to you... - 1. resolve the conflict in whichever way you choose, - 1. add and commit the changes on main -1. Merging ex2 branch into main branch... the difference here is metadata and binaries from a plot - 1. first look at the diff - 1. now checkout e2. - 1. remove the metadata and outputs by clearing all cell output - 1. add and commit the changes on e2 - 1. now merge e2 into main - 1. resolve the conflict in whichever way you choose, - 1. add and commit the changes on main +This exercise assumes you are using recent Jupyterlab with the git extension built on nbdime. For this quarter in COGS108 those assumptions are true on Datahub. If you try this on your local computer this may or may not be true. If you are using VSCode on your local computer or something else entirely, there are other ways of doing these operations... you should figure it out yourself for whatever tools you like to use! + +This repo contains two branches: main and ex1. There is a single line text conflict in one cell between the two branches. The goal is to merge branch ex1 into branch main. + + +1. Clone this repo to your datahub or local computer. In a terminal window type `git clone https://github.com/COGS108/GitExercise_Conflicts.git` +2. This clone only brings the main branch to your computer... we also need a local copy of the ex1 branch which you can get by typing the following two lines of code in the terminal (press return each time) +`cd GitExercise_Conflicts`
+`git checkout -b ex1 origin/ex1` +that last line sets up a local branch called ex1 to track the remote branch of the same name (origin is git's word for the remote repo) +3. We want to merge ex1 into main, not the other way around! The merge command assumes the branch you're in right now is the destination, but the checkout command above put us on ex1. Let's hop back to main to do this right... type `git checkout main` +4. Ok now we have both branches locally, and we are ready to merge ex1 into main. Let's see what the difference between branches actually is. Type `git diff ex1` +5. Now merge ex1 into main by typing `git merge ex1` ... and yes it will give you the conflict message we expect +6. Up to this point I very purposefully did NOT tell you to open Project.ipynb... if you try to double click on the notebook now you will get an error message telling you that file is NOT correct JSON. This is becuase the merge conflict has broken the syntax of a notebook file... a snippit of the file will at this moment look like: +```python + "ax.set(xlabel='time (s)', ylabel='voltage (mV)',\n", +<<<<<<< HEAD + " title='The simplest plot in the world')\n", +======= + " title='This plot is simple!')\n", +>>>>>>> ex1 + "ax.grid()" +``` +and all those greater than/less than/equals symbols set off the conflict and also break JSON syntax. So you can't look at this merged/conflicted notebook the way you normally do. +7. Let's use Jupyterlabs built in git extensions to view and deal with the conflict. First go to the far left of the window, and you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. +8. Now you will see a set of panels, one of which shows Conflicted files... there it is Project.ipynb! Double click to open a tool for resolving the conflict +9. The tool shows 3 versions of the conflicted cell from left to right... the current (main), the most recent ancestor when both branches were the same, and the incoming branch (ex1). Underneath those 3 panels is a fourth panel... this is the one you edit to resolve the conflict +10. Change the fourth panel to be whatever you want the end result to be. +11. Click the "Mark as resolved" button the top right, now you will see Project.ipynb change from the Conflicted to Staged (the tool automagically did a `git add` for you) +12. You can actually make the commit right underneat the Staged file... make sure to put a message in to the commit before you press the commit button! +ommit the changes on e2 + + +Congrats!! You've dealt with a VERY SIMPLE version of the notebook conflict problem. + +And now you know why version control with notebooks is hard! It would have been slightly easier with a normal set of .py files. It could have been a lot harder if the notebooks involved hadn't had all their outputs cleared before commit. When notebooks have metadata or binary data from the actual plot stored in the .ipynb file version control can be even more annyoing. From b519da229763ef4b6d06b73d0822c1da47887895 Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Thu, 3 Apr 2025 22:01:46 -0700 Subject: [PATCH 03/12] formatting fix --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index d7633df..66a90b1 100644 --- a/README.md +++ b/README.md @@ -6,15 +6,15 @@ This repo contains two branches: main and ex1. There is a single line text confl 1. Clone this repo to your datahub or local computer. In a terminal window type `git clone https://github.com/COGS108/GitExercise_Conflicts.git` -2. This clone only brings the main branch to your computer... we also need a local copy of the ex1 branch which you can get by typing the following two lines of code in the terminal (press return each time) +2. This clone only brings the main branch to your computer... we also need a local copy of the ex1 branch which you can get by typing the following two lines of code in the terminal (press return each time)
`cd GitExercise_Conflicts`
-`git checkout -b ex1 origin/ex1` +`git checkout -b ex1 origin/ex1`
that last line sets up a local branch called ex1 to track the remote branch of the same name (origin is git's word for the remote repo) 3. We want to merge ex1 into main, not the other way around! The merge command assumes the branch you're in right now is the destination, but the checkout command above put us on ex1. Let's hop back to main to do this right... type `git checkout main` 4. Ok now we have both branches locally, and we are ready to merge ex1 into main. Let's see what the difference between branches actually is. Type `git diff ex1` 5. Now merge ex1 into main by typing `git merge ex1` ... and yes it will give you the conflict message we expect 6. Up to this point I very purposefully did NOT tell you to open Project.ipynb... if you try to double click on the notebook now you will get an error message telling you that file is NOT correct JSON. This is becuase the merge conflict has broken the syntax of a notebook file... a snippit of the file will at this moment look like: -```python +```JSON "ax.set(xlabel='time (s)', ylabel='voltage (mV)',\n", <<<<<<< HEAD " title='The simplest plot in the world')\n", From 7a544bdb8d9631255be1de2e758c06432b0cd4fe Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Thu, 3 Apr 2025 22:02:54 -0700 Subject: [PATCH 04/12] another formatting fix --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 66a90b1..a806d8b 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,8 @@ that last line sets up a local branch called ex1 to track the remote branch of t "ax.grid()" ``` and all those greater than/less than/equals symbols set off the conflict and also break JSON syntax. So you can't look at this merged/conflicted notebook the way you normally do. -7. Let's use Jupyterlabs built in git extensions to view and deal with the conflict. First go to the far left of the window, and you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. + +7. Let's use Jupyterlab's built in git extensions to view and deal with the conflict. First go to the far left of the window, and you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. 8. Now you will see a set of panels, one of which shows Conflicted files... there it is Project.ipynb! Double click to open a tool for resolving the conflict 9. The tool shows 3 versions of the conflicted cell from left to right... the current (main), the most recent ancestor when both branches were the same, and the incoming branch (ex1). Underneath those 3 panels is a fourth panel... this is the one you edit to resolve the conflict 10. Change the fourth panel to be whatever you want the end result to be. From 875c77276316d3c4f3a5f2c4c816d6577bc0d3d1 Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Fri, 4 Apr 2025 08:53:46 -0700 Subject: [PATCH 05/12] Update exercise with a harder part 2 --- README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/README.md b/README.md index a806d8b..7e8b02b 100644 --- a/README.md +++ b/README.md @@ -37,3 +37,11 @@ ommit the changes on e2 Congrats!! You've dealt with a VERY SIMPLE version of the notebook conflict problem. And now you know why version control with notebooks is hard! It would have been slightly easier with a normal set of .py files. It could have been a lot harder if the notebooks involved hadn't had all their outputs cleared before commit. When notebooks have metadata or binary data from the actual plot stored in the .ipynb file version control can be even more annyoing. + +Ready to try a harder version of the merge? +13. On main branch, open Project.ipynb as a notebook and select Run All. Now save the notebook. +14. Stage and commit the changes (you are storing the metadata and binaries fo the image in git) +15. checkout the ex1 branch +16. change the figuresize argument slightly +17. run all, save, stage and commit on ex1.... the binary is now different on ex1 than on main +18. attempt to merge ex1 into main again... this time with more annoying merge issues :) From fdd816ccfc4c12dc65cd1de1e226efd012975e17 Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Fri, 4 Apr 2025 08:58:52 -0700 Subject: [PATCH 06/12] Update formatting --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 7e8b02b..666c044 100644 --- a/README.md +++ b/README.md @@ -39,6 +39,7 @@ Congrats!! You've dealt with a VERY SIMPLE version of the notebook conflict prob And now you know why version control with notebooks is hard! It would have been slightly easier with a normal set of .py files. It could have been a lot harder if the notebooks involved hadn't had all their outputs cleared before commit. When notebooks have metadata or binary data from the actual plot stored in the .ipynb file version control can be even more annyoing. Ready to try a harder version of the merge? + 13. On main branch, open Project.ipynb as a notebook and select Run All. Now save the notebook. 14. Stage and commit the changes (you are storing the metadata and binaries fo the image in git) 15. checkout the ex1 branch From 1572073a2aff4d7e561430ac204a28f3c531b2d9 Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Fri, 29 Aug 2025 15:11:05 -0700 Subject: [PATCH 07/12] Updated instructions for Jupyterlab Github GUI Also added a part 1 that walks them through a simple stage-commit cycle before tackling the merge in part 2. --- README.md | 87 +++++++++++++++++++++++++++---------------------------- 1 file changed, 43 insertions(+), 44 deletions(-) diff --git a/README.md b/README.md index 666c044..785eafa 100644 --- a/README.md +++ b/README.md @@ -1,48 +1,47 @@ # GitExercise_Conflicts -This exercise assumes you are using recent Jupyterlab with the git extension built on nbdime. For this quarter in COGS108 those assumptions are true on Datahub. If you try this on your local computer this may or may not be true. If you are using VSCode on your local computer or something else entirely, there are other ways of doing these operations... you should figure it out yourself for whatever tools you like to use! - -This repo contains two branches: main and ex1. There is a single line text conflict in one cell between the two branches. The goal is to merge branch ex1 into branch main. - - -1. Clone this repo to your datahub or local computer. In a terminal window type `git clone https://github.com/COGS108/GitExercise_Conflicts.git` -2. This clone only brings the main branch to your computer... we also need a local copy of the ex1 branch which you can get by typing the following two lines of code in the terminal (press return each time)
-`cd GitExercise_Conflicts`
-`git checkout -b ex1 origin/ex1`
-that last line sets up a local branch called ex1 to track the remote branch of the same name (origin is git's word for the remote repo) -3. We want to merge ex1 into main, not the other way around! The merge command assumes the branch you're in right now is the destination, but the checkout command above put us on ex1. Let's hop back to main to do this right... type `git checkout main` -4. Ok now we have both branches locally, and we are ready to merge ex1 into main. Let's see what the difference between branches actually is. Type `git diff ex1` -5. Now merge ex1 into main by typing `git merge ex1` ... and yes it will give you the conflict message we expect -6. Up to this point I very purposefully did NOT tell you to open Project.ipynb... if you try to double click on the notebook now you will get an error message telling you that file is NOT correct JSON. This is becuase the merge conflict has broken the syntax of a notebook file... a snippit of the file will at this moment look like: -```JSON - "ax.set(xlabel='time (s)', ylabel='voltage (mV)',\n", -<<<<<<< HEAD - " title='The simplest plot in the world')\n", -======= - " title='This plot is simple!')\n", ->>>>>>> ex1 - "ax.grid()" -``` -and all those greater than/less than/equals symbols set off the conflict and also break JSON syntax. So you can't look at this merged/conflicted notebook the way you normally do. - -7. Let's use Jupyterlab's built in git extensions to view and deal with the conflict. First go to the far left of the window, and you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. -8. Now you will see a set of panels, one of which shows Conflicted files... there it is Project.ipynb! Double click to open a tool for resolving the conflict -9. The tool shows 3 versions of the conflicted cell from left to right... the current (main), the most recent ancestor when both branches were the same, and the incoming branch (ex1). Underneath those 3 panels is a fourth panel... this is the one you edit to resolve the conflict -10. Change the fourth panel to be whatever you want the end result to be. -11. Click the "Mark as resolved" button the top right, now you will see Project.ipynb change from the Conflicted to Staged (the tool automagically did a `git add` for you) -12. You can actually make the commit right underneat the Staged file... make sure to put a message in to the commit before you press the commit button! -ommit the changes on e2 +This exercise assumes you are using recent COGS 108 Datahub setup (which is Jupyterlab with the git extension built on nbdime). But you can do everything here using your own computer if you set it up with the same tools. If you are using git command line or VSCode, or something else entirely then you can still do this exercise, but the step by step insructions will need you to adapt them to your tools. There is always more than one way to get something done, just learn and use the tool that you prefer! + +This repo contains two branches: main and ex1. There is a single line text conflict in one cell between the two branches. The goal of this exercise is +twofold; to learn how to stage and commit changes to a branch and then to learn how to merge the changes from one branch to another. + +We will do two seperate git operations +- add a new change to branch main, thus introducing a second difference with ex1 branch +- then we will merge the changes from branch ex1 into main + +Here are step-by-step instructions assuming that you have logged in to Datahub to do this: +- Use the file browser to make sure you are in a directory you are allowed to write new files to, e.g. the `private` directory inside your home directory. Double click on the file browser to set your current working location to whatever is best for how you want to organize files. Wherever you are in the file browser is where the new git repo will be created. +- On the far left you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. +- Click the button "Clone a Repository" and use `https://github.com/COGS108/GitExercise_Conflicts.git` as the remote repo URL. Click the button that says `Clone` +- Your new repository will appear in the file browser... double click on the new folder `GitExercise_Conflicts` to go inside and view the files! + +Part I - Make a local change on main +- Open `Project.ipynb` +- Just for fun, run both cells of the notebook to see the plot +- Lets add a change: the last line of the notebook currently says `ax.grid()` which is bad Python form... yeah it works to turn on the grid lines of the plot implicitly, but it would be much more human readable if we used the more Pythonic `ax.grid('on')`. Please make that change and don't forget to save the file when you are done! +- On the far left you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. +- At the bottom of the git panel you can see there are three categories of files that could be the subject of git operations
+ "Untracked" for new files you create that are not yet in the repo
+ "Changed" for files already in the repo, but you changed something
+ "Staged" which tracks all the changes you've asked to be grouped together into a commit
+- Look at the "Changed" section, `Project.ipynb` is there... hover your mouse over it. You will see icons for opening the file, for making a diff summary of the changes, for discarding the changes, and one for staging the changes for a commit (a + symbol). Stage the changes! +- Now that `Project.ipynb` is in the "Staged" category you can scroll down to the bottom of the git panel and commit the changes. Add a summary (<50 characters), something like "improved code readability". There is also a space for longer description if necessary. Press the "Commit" button, and you're done with Part I! + +Part II - Merge ex1 into main +- On the git panel there's a place at the top where it says "Current Branch: main"; click on that menu item to see a list of all the branches available. When you cloned the repository you only got a copy of the default branch (called "main")... there were other branches but they are still only on the remote repo up on GitHub. Remote branches are marked with the keyword "origin". So "main" is a local branch, "origin/main" is the main branch on GitHub and likewise "origin/ex1" is on Github. Click on that last branch... +- Previously you had only "origin/ex1" and not "ex1", but now you do! By clicking on "origin/ex1" git made a local branch "ex1" and set it up to track the remote branch "origin/ex1". Now that we have local copies of both main and ex1 we can merge the branches. ex1 will be merged into main! +- OK here's the task: we want to merge the change in branch ex1 (a change of title on the graph) into main, erasing the old title. But we want to keep our explicit `ax.grid('on')` change which is only on main and not ex1. +- Here's how to do it... click on "main" to make sure we are currently on the main branch. We want to be on the branch that is the destination of the merge. +- Hover over the local "ex1" branch and a button icon that looks like 3 dots with connecting lines will appear.. when you hover over the button it says "merge this branch into the current one"... go ahead and click it! +- You will get an error message "Failed to merge ex1 into main". And now there is a new category "Conflicted" just above "Staged"! Our file `Project.ipynb` is in that heading as expected! Hover over the file, and click on the icon to "diff this file" that appears. +- You will now see the diff panel... where there are conflicts you have from left to right three possiblities:
+ "Current" (what was in main before the merge)
+ "Common Ancestor" (what the file looked like when ex1 split off from main)
+ "Incoming" (what was in ex1 before the merge)
+ Underneath the triple column you will see a panel where you can manually change the conflict zone to make the outcome what you want. Whatever you put in this lower panel is what the outcome of the merge will be! +- Make the outcome of the merge to be the ex1 title and the main ax.grid('on') command! Save it by clicking the button on the top right that says "Mark as resolved". You will see that `Project.ipynb` moved from "Conflicted" to "Staged" +- Go look at the notebook and make sure it is what you wanted it to be. It is also useful at this stage to run-all to ensure that the Frankenstein's monster of code from both branches is actually functional as a combo. You will get a warning that you have made changes that are unsaved because every time a notebook runs it changes metadata stored inside it. Ignore that... if you press save again you will add a new set of changes that need to be staged and committed, but those changes are USELESS... its just increments to the run counter of the cells and the exact binary data of the plot generated. +- Let's commit the merge! On the git panel give it a summary (something like "merged ex1 into main") and press the commit button. -Congrats!! You've dealt with a VERY SIMPLE version of the notebook conflict problem. - -And now you know why version control with notebooks is hard! It would have been slightly easier with a normal set of .py files. It could have been a lot harder if the notebooks involved hadn't had all their outputs cleared before commit. When notebooks have metadata or binary data from the actual plot stored in the .ipynb file version control can be even more annyoing. - -Ready to try a harder version of the merge? - -13. On main branch, open Project.ipynb as a notebook and select Run All. Now save the notebook. -14. Stage and commit the changes (you are storing the metadata and binaries fo the image in git) -15. checkout the ex1 branch -16. change the figuresize argument slightly -17. run all, save, stage and commit on ex1.... the binary is now different on ex1 than on main -18. attempt to merge ex1 into main again... this time with more annoying merge issues :) +Congrats!! You've dealt with a simple version of the notebook conflict problem. This workflow will happen in your projects all the time, when person A and person B need to merge their seperate parts of the project together into the final project. From 550d5ad31da9d7a7b802ecdb8db3cba5dd5443a2 Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Fri, 29 Aug 2025 15:17:07 -0700 Subject: [PATCH 08/12] Clear all outputs instruction added --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 785eafa..04b0248 100644 --- a/README.md +++ b/README.md @@ -18,6 +18,7 @@ Here are step-by-step instructions assuming that you have logged in to Datahub t Part I - Make a local change on main - Open `Project.ipynb` - Just for fun, run both cells of the notebook to see the plot +- Unfortunately running the notebook changes the metadata stored inside it. The counter for how many times a cell was run, the binary data from the plot. This is stuff we do NOT want to version control... its not important and it clogs up the system because notebook metadata for plots can be very big. Before we do any git operations it is a best practice to click on the pulldown menu item `Edit -> Clear Outputs of All Cells` - Lets add a change: the last line of the notebook currently says `ax.grid()` which is bad Python form... yeah it works to turn on the grid lines of the plot implicitly, but it would be much more human readable if we used the more Pythonic `ax.grid('on')`. Please make that change and don't forget to save the file when you are done! - On the far left you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. - At the bottom of the git panel you can see there are three categories of files that could be the subject of git operations
From d531e1804ea665fa78079aa50b0d5dc3d928e68b Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Mon, 1 Sep 2025 14:19:15 -0700 Subject: [PATCH 09/12] Added graph explanations of the exercise --- README.md | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 04b0248..1172437 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,29 @@ # GitExercise_Conflicts -This exercise assumes you are using recent COGS 108 Datahub setup (which is Jupyterlab with the git extension built on nbdime). But you can do everything here using your own computer if you set it up with the same tools. If you are using git command line or VSCode, or something else entirely then you can still do this exercise, but the step by step insructions will need you to adapt them to your tools. There is always more than one way to get something done, just learn and use the tool that you prefer! +This exercise assumes you are using the COGS 108 Datahub setup. But you can do everything here using your own computer if you set it up with the same tools (which is recent Jupyterlab with the git extension built on nbdime). If you are using git command line or VSCode, or something else entirely then you can still do this exercise, but the step by step insructions will need to be adapted to your tools. There is always more than one way to get something done, just learn and use the tool that you prefer! This repo contains two branches: main and ex1. There is a single line text conflict in one cell between the two branches. The goal of this exercise is -twofold; to learn how to stage and commit changes to a branch and then to learn how to merge the changes from one branch to another. +two-fold; to learn how to stage and commit changes to a branch and then to learn how to merge the changes from one branch to another. + +Below is a graph of the commit situation in the repo right now... the commits on each branch have produced a single line conflict you need to deal with before merging +----*----*[main] + \ + \----*[ex1] We will do two seperate git operations -- add a new change to branch main, thus introducing a second difference with ex1 branch -- then we will merge the changes from branch ex1 into main +- [Part 1] add a new change to branch main, thus introducing a second difference with ex1 branch +- [Part 2] then we will merge the changes from branch ex1 into main + +Thus after Part 1 the new graph will look like +----*----*----*[main] + \ + \----*[ex1] +And after Part 2 the new graph will look like +----*----*----*----*[main] + \ / + \----*------/ + Here are step-by-step instructions assuming that you have logged in to Datahub to do this: - Use the file browser to make sure you are in a directory you are allowed to write new files to, e.g. the `private` directory inside your home directory. Double click on the file browser to set your current working location to whatever is best for how you want to organize files. Wherever you are in the file browser is where the new git repo will be created. - On the far left you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. From 8efbbb7fa55c060221388dc01ad2bc0a7ba1c7b5 Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Thu, 4 Sep 2025 14:38:49 -0700 Subject: [PATCH 10/12] Added fork instructions in prep for autograding --- README.md | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 1172437..9013c4a 100644 --- a/README.md +++ b/README.md @@ -6,29 +6,42 @@ This repo contains two branches: main and ex1. There is a single line text confl two-fold; to learn how to stage and commit changes to a branch and then to learn how to merge the changes from one branch to another. Below is a graph of the commit situation in the repo right now... the commits on each branch have produced a single line conflict you need to deal with before merging + +``` ----*----*[main] \ \----*[ex1] +``` We will do two seperate git operations - [Part 1] add a new change to branch main, thus introducing a second difference with ex1 branch - [Part 2] then we will merge the changes from branch ex1 into main Thus after Part 1 the new graph will look like + +``` ----*----*----*[main] \ \----*[ex1] +``` And after Part 2 the new graph will look like + +``` ----*----*----*----*[main] \ / \----*------/ - -Here are step-by-step instructions assuming that you have logged in to Datahub to do this: -- Use the file browser to make sure you are in a directory you are allowed to write new files to, e.g. the `private` directory inside your home directory. Double click on the file browser to set your current working location to whatever is best for how you want to organize files. Wherever you are in the file browser is where the new git repo will be created. +``` + +To work on this exercise: +- Fork this repo by pressing the Fork button at the top of this webpage. Forking this repo make a copy of this repo on YOUR github. You own this fork, you can change it however you like. +- The original repo was at `https://github.com/COGS108/GitExercise_Conflicts.git`, your forked copy will be located at `https://github.com/your_username/GitExercise_Conflicts.git` where you must replace `your_username` with your actual GitHub username. +- Note that the fork is a remote copy on GitHub... you will have to go to Datahub, login, and get a local copy of the fork (NOT the original) repo there. +- Let's get that local copy... login to Datahub. +- Use the Datahub file browser to make sure you are in a directory you are allowed to write new files to, e.g. the `private` directory inside your home directory. Double click on the file browser to set your current working location to whatever is best for how you want to organize files. Wherever you are in the file browser is where the new git repo will be created. - On the far left you will see a vertical stack of icons in a grey panel. Click on the one that's a diamond with some lines inside it, that's the git panel. -- Click the button "Clone a Repository" and use `https://github.com/COGS108/GitExercise_Conflicts.git` as the remote repo URL. Click the button that says `Clone` -- Your new repository will appear in the file browser... double click on the new folder `GitExercise_Conflicts` to go inside and view the files! +- Click the button "Clone a Repository" and set remote URL to `https://github.com/your_username/GitExercise_Conflicts.git` where you must replace `your_username` with your actual GitHub username. Click the button that says `Clone` +- Your new local copy of the repository will appear in the file browser... double click on the new folder `GitExercise_Conflicts` to go inside and view the files! Part I - Make a local change on main - Open `Project.ipynb` @@ -59,5 +72,12 @@ Part II - Merge ex1 into main - Go look at the notebook and make sure it is what you wanted it to be. It is also useful at this stage to run-all to ensure that the Frankenstein's monster of code from both branches is actually functional as a combo. You will get a warning that you have made changes that are unsaved because every time a notebook runs it changes metadata stored inside it. Ignore that... if you press save again you will add a new set of changes that need to be staged and committed, but those changes are USELESS... its just increments to the run counter of the cells and the exact binary data of the plot generated. - Let's commit the merge! On the git panel give it a summary (something like "merged ex1 into main") and press the commit button. +Finally +- All the changes you've made so far only exist in the local copy on Datahub. We need to push the changes from the local copy to your forked copy. +- On the top left are a set of cloud icons, one with the arrow pointed down (that's pull) and one with the arrow pointed up (that's push). +- If there's a red dot on one of the clouds you need to do that action. In this case you only need to push. Once you've pushed your exercise is done... the changes you've made have appeared on GitHub and are visible to other people including our auto-grading scripts. + + +Congrats!! You've dealt with a simple version of the notebook conflict problem. This workflow will happen in your projects all the time, when person A and person B need to merge their seperate parts of the project together into the final project. -Congrats!! You've dealt with a simple version of the notebook conflict problem. This workflow will happen in your projects all the time, when person A and person B need to merge their seperate parts of the project together into the final project. +Another common project workflow is if there's a red dot on pull (down arrow) that means someone else made changes to the remote that you don't have. Pull operations need to be done before push operations... so if someone changed the remote after your clone but before your push you will have to pull first, merge, and resolve any conflicts before you are allowed to push your changes to remote. We didn't have to do that here, but its a very normal workflow for your projects. From 7ec6884ec27d328c48493c6430b67188cabe7d4c Mon Sep 17 00:00:00 2001 From: Jason Fleischer Date: Tue, 14 Oct 2025 21:52:16 -0700 Subject: [PATCH 11/12] Update README with detailed forking and pushing steps Clarified forking instructions and emphasized the importance of pushing changes. --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 9013c4a..6b0c2a3 100644 --- a/README.md +++ b/README.md @@ -34,7 +34,8 @@ And after Part 2 the new graph will look like ``` To work on this exercise: -- Fork this repo by pressing the Fork button at the top of this webpage. Forking this repo make a copy of this repo on YOUR github. You own this fork, you can change it however you like. +- Fork this repo by pressing the Fork button at the top of this webpage. When you fork it MAKE SURE you **UNCHECK** the default option to "Copy the main branch only". You want all the branches! +- Forking this repo made a copy of this repo on YOUR GitHub. You own this fork, you can change it however you like. - The original repo was at `https://github.com/COGS108/GitExercise_Conflicts.git`, your forked copy will be located at `https://github.com/your_username/GitExercise_Conflicts.git` where you must replace `your_username` with your actual GitHub username. - Note that the fork is a remote copy on GitHub... you will have to go to Datahub, login, and get a local copy of the fork (NOT the original) repo there. - Let's get that local copy... login to Datahub. @@ -76,7 +77,7 @@ Finally - All the changes you've made so far only exist in the local copy on Datahub. We need to push the changes from the local copy to your forked copy. - On the top left are a set of cloud icons, one with the arrow pointed down (that's pull) and one with the arrow pointed up (that's push). - If there's a red dot on one of the clouds you need to do that action. In this case you only need to push. Once you've pushed your exercise is done... the changes you've made have appeared on GitHub and are visible to other people including our auto-grading scripts. - +- **IF YOU DON'T PUSH AT THE END OF THE EXERCISE YOU WILL LOSE POINTS ON THE AUTOGRADER** Congrats!! You've dealt with a simple version of the notebook conflict problem. This workflow will happen in your projects all the time, when person A and person B need to merge their seperate parts of the project together into the final project. From 81c35db521d5aafe3c55350f499f70fd3139708c Mon Sep 17 00:00:00 2001 From: amunshi10 Date: Thu, 23 Oct 2025 00:33:47 -0700 Subject: [PATCH 12/12] Change ax.grid() to ax.grid('on') in Project.ipynb --- Project.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Project.ipynb b/Project.ipynb index f9e17ce..c554e60 100644 --- a/Project.ipynb +++ b/Project.ipynb @@ -27,7 +27,7 @@ "\n", "ax.set(xlabel='time (s)', ylabel='voltage (mV)',\n", " title='This plot is simple!')\n", - "ax.grid()" + "ax.grid('on')" ] } ],