CHEM 169/269 Climbing Gym

Route 008: The Crowded Arete

RouteID: 008
Wall: The Crowded Arete
Grade: 5.9
Routesetter: Srikar + Adrian + Sarah
Time: ~30-45 minutes

Introduction

In real research and ML projects, often you don’t work alone. Code lives in shared repositories, and multiple people often try to change things at the same time. This route is designed to intentionally create friction. You and your belay partner will:

Work on the same GitHub repository
Make overlapping changes
Experience push rejections
Learn why Git complains → and what it’s trying to protect

Confusion is expected. Conflicts are the point.

Learning Objectives

By the end of this route, you should be able to:

Explain why Git sometimes rejects a push
Understand the difference between local state and remote state
Describe what a merge conflict is, even if you don’t fully resolve one
Develop good habits for collaborating with others

This is not about perfection — it’s about situational awareness.

Instructions

Setup (Partner Required)

Form a pair (2 climbers per rope)
One shared GitHub repository is provided
Both partners clone the same repository

🧠 Think of this like two climbers starting on opposite sides of the same arete.

Exercise 1: Parallel moves (the calm before the storm)

Goal: Get both partners working on the same repo without interference.

Partner A makes a small change to a file
Partner B makes a different small change to the same file
Both commit locally

Checkpoint: At this point, both of you have:

Clean working trees
Commits that exist only on your own machines

No conflict yet. This is deceptive.

Exercise 2: First push wins

Goal: See what happens when only one climber tops out first.

Partner A pushes their changes to GitHub
Partner B does not pull yet

Observe:

The remote repository has now changed
Partner B’s local copy is now behind the remote

Exercise 3: The rejection (intentional crux)

Goal: Experience a failed push and read the error message.

Partner B tries to push their changes without pulling first

What should happen:

Git rejects the push
You see an error message about:
- non-fast-forward updates
- remote changes
- needing to pull first

Task: Don’t fix anything yet. Read the error message carefully and discuss:

What is Git protecting?
Why doesn’t Git just overwrite the remote?

Exercise 4: Pulling into conflict

Goal: Bring the two histories together.

Partner B pulls the remote changes
Git attempts to merge histories

Depending on the edits:

You may see an automatic merge
Or you may trigger a merge conflict

Either outcome is valid.

Exercise 5: Conflict awareness (not mastery)

Goal: Understand what a merge conflict means. If a conflict occurs:

Open the file
Look for conflict markers (<<<<<<, ======, >>>>>>)
Identify:
- “their version”
- “your version”

You do not need to fully resolve the conflict unless instructed. Key question: Why can’t Git decide automatically?

Exercise 6: Debrief at the anchor

Before moving on, answer together:

When is it safe to push?
Why is pulling before pushing a good habit?
How does this change how you’d work on a real project?

Deliverables

Goal: Create a "Summit Log" that proves you and your partner successfully merged your two paths.

Exercise 7: The Summit Photo

The Beta: Each github partner should submit their own file with their lastname_firstname information.

Do: Partner B (the one who pulled/merged) should run these two commands in the terminal:

Generate the Log: git log -n 5 > deliverable_RID_008.txt (This captures only the last 5 "clips" or commits, ensuring the file isn't 20 pages long.)
Add the Remote Info: git remote -v >> deliverable_RID_008.txt (This proves you were both working on the same shared "Arete" repository.)

Individual Logbook Entry

Each climber must submit their own short reflection (lastname_firstname_RID_008_logbook.txt) answering:

What did the Git error message say when your push was rejected?
In your own words, why is it safer for Git to "annoy" you with a rejection than to just overwrite the code?

SUBMIT LINK