fix episode 3 revision

[zkamvar]

This addresses the accidental reversion that happened in https://github.com/datacarpentry/r-raster-vector-geospatial/pull/387

see https://github.com/carpentries/sandpaper/issues/411#issuecomment-1480169622 for details

[github-actions[bot]]

Thank you!

Thank you for your pull request :smiley:

:robot: This automated message can help you check the rendered files in your submission for clarity. If you have any questions, please feel free to open an issue in {sandpaper}.

If you have files that automatically render output (e.g. R Markdown), then you should check for the following:

• :dart: correct output
• :framed_picture: correct figures
• :question: new warnings
• :bangbang: new errors

Rendered Changes

:mag: Inspect the changes: https://github.com/datacarpentry/r-raster-vector-geospatial/compare/md-outputs..md-outputs-PR-407

The following changes were observed in the rendered markdown documents:

 03-raster-reproject-in-r.md                        | 368 ++++++++++-----------
 ...in-r-rendered-challenge-code-reprojection-1.png | Bin 210212 -> 232693 bytes
 ...ter-reproject-in-r-rendered-plot-DTM-hill-1.png | Bin 49505 -> 49855 bytes
 ...oject-in-r-rendered-plot-projected-raster-1.png | Bin 129256 -> 141502 bytes
 md5sum.txt                                         |   2 +-
 5 files changed, 178 insertions(+), 192 deletions(-)

What does this mean?

If you have source files that require output and figures to be generated (e.g. R Markdown), then it is important to make sure the generated figures and output are reproducible. This output provides a way for you to inspect the output in a diff-friendly manner so that it's easy to see the changes that occur due to new software versions or randomisation.

:stopwatch: Updated at 2023-03-23 13:20:45 +0000

[drakeasberry]

Thanks @zkamvar for putting this PR together. I am still a bit unclear as to what happened in these oddities. Particularly, with the last merge, new-m2022q1_e3, because I was able to serve the website using sandpaper and see the changes reflected accurately. Then once I merged into main, I could only see the reversion of changes again.

[zkamvar]

Thanks @zkamvar for putting this PR together. I am still a bit unclear as to what happened in these oddities. Particularly, with the last merge, new-m2022q1_e3, because I was able to serve the website using sandpaper and see the changes reflected accurately. Then once I merged into main, I could only see the reversion of changes again.

I updated my comment, but I think this diagram may help. In essence, I think what happened is that, normally, what should have happened is that one branch for each episode should have been created from the same source commit:

---
title: "Ideal situation: origin commit identical"
---
gitGraph
   commit id: "231af26"
   branch episode-3
   checkout episode-3
   commit id: "c67c61a (ep 3)"
   checkout main
   branch episode-4
   checkout episode-4
   commit id: "??????? (ep 4)"
   checkout main
   merge episode-3
   checkout main
   merge episode-4

Instead, what happened was the branch for episode 4 was created from the branch from episode 3, so the commit was brought over, so the reversion was valid. (Note: you can safely ignore the "cherry-pick" there. I had to do that to get the graph to do what I wanted it to do)

---
title: Episode 4 branch created from episode 3 branch
---
gitGraph
   commit id: "231af26"
   branch changes
   checkout changes
   commit id: "c67c61a (ep 3)"
   branch episode-3
   checkout episode-3
   cherry-pick id: "c67c61a (ep 3)"
   branch episode-4
   checkout episode-4
   commit id: "2461571 (e 4)" type: HIGHLIGHT
   checkout main
   merge episode-3
   checkout episode-4
   commit id: "f7f6c2c (rev ep 3)" type: REVERSE
   checkout main
   merge episode-4