Mental model change to versions and computed differences

[twhitehead]

This is my take on the alternative wording/metal model as discussed in #149

[jiffyclub]

I think this description is not as powerful as the tape analogy. I think we want to use this intro to express the power of a VCS as a document history tracker, not a system for generating diffs.

[rgaiacs]

I think we want to use this intro to express the power of a VCS as a document history tracker, not a system for generating diffs.

I agree on that.

[daisieh]

+1

[daisieh]

I think that this section should focus on VCSes in general and the things that they can do, even if we don't get around to teaching everything about them in the bootcamp. This is why I like the tape analogy; I also think that thinking about "changes" instead of "differences" is a little more familiar to people who have used "Track Changes" before.

[twhitehead]

Thanks for all the feedback.

I was attempting to keep as much of the original spirt as possible. It seemed to me the original author had felt thinking in terms of diffs was an "ah ha" moment so I didn't want to remove that. I will try again in a bit (not likely till next week).

I don't think I'm following everyone one the tape analogy though. Why in it so good? What exactly does it give us beyond the direct physical link to "playing back"? Do kids even still relate to tapes nowadays?

Personally, I don't recall getting a lot of insight out of the idea of differential encoding back when I learned RCS and CVS beyond the fact that it was a clever way to save disk space. Perhaps I'm forgetting though. Was your experiences different?

[jiffyclub]

I'm personally not attached to any discussion of diffs in the intro here. (We can talk about diffs all we want when we introduce git diff.) I'm fine with say things like "a VCS stores versions". Whatever we feel most clearly describes the utility of a VCS as a system for logging the history of a project.

Tapes are a little anachronistic but I think the analogy still works. People know what "rewind" and "play" mean. The analogy I like to use is of photography and a photo album, but then I like photography.

[wking]

On Wed, May 27, 2015 at 08:16:29PM -0700, Tyson Whitehead wrote:

I don't think I'm following everyone one the tape analogy though.

I see #149 was just closed, but I quite like the photography analogy
with commits as snapshots, and the history being a stack/graph of
snapshots. I remember @ChristinaLK actually bringing in a physical
camera to help demonstrate the concept. Besides reflecting Git's
“commits point to trees” model, it makes it clear how you can go back
and look at a previous snapshot, and also extends nicely to ‘git add’
and staging in index (“composing the picture”).

[daisieh]

Here's the confusing thing for me about using photography: it's unclear to me how you'd diff two snapshots. Like, would it be "how many things are different between these two pictures?"

[wking]

On Sat, Nov 14, 2015 at 11:59:06AM -0800, Daisie Huang wrote:

Here's the confusing thing for me about using photography: it's
unclear to me how you'd diff two snapshots. Like, would it be "how
many things are different between these two pictures?"

Yeah, and that's how Git does it. I think subtracting pictures is
something that folks know computers are good at, even if it's hard for
people (and this also applies to computing diffs ;).

[justbennet]

I came up with a different analogy, if I may add that here. I'd appreciate feedback on it.

Back in the day, I typed my thesis on using a manual typewriter, not even electric. Here's how it went. I typed a kind of outline, with some paragraphs of real text, double-spaced. Then I took those pages to the coffeehouse and made changes to them with a pen. After I made enough changes, I retyped my chapter incorporating all the changes. I put the marked up pages into a folder, dated it, and repeated the process. I did this for each of the chapters. Once I had several chapters, I'd make changes, but they would only be to one section at a time, so I'd mark those and put them in a basket, and when I got a good set of changes, I would set about retyping again. Every time I retyped something, the marked up original went into a folder with a date.

This is quite a bit like how Git works. You start by typing a bunch. Then you save a draft. Now you add a few more files, and you save some more. When you want to go back and revise existing pages, you make those changes, then you put them in the basket for retyping by using git add. When you get a set of changes that makes sense, you git commit, and that's like making the fair copy from all the accumulated changes in the basket. Those folders with the dates on them are like each commit, and they contain the record of what you changed.

Sorry, my English is a bit clumsy here. I'd work on it some more if people thought it had any promise.

[wking]

On Fri, Apr 22, 2016 at 04:18:49PM -0700, justbennet:
“Back in the day, I typed my thesis…”

I like this analogy, which even has some commit-message and/or
diff-like properties in the coffeehouse markup (although to quibble,
Git is usually computing its diffs on the fly).

Comparing the three:

Git | Photography | Thesis
----------+--------------------+---------------------
file | anything | page/section
index | lightbox | basket
commit | snapshot | dated folder
branch | stack of snapshots | filing cabinet
diff | subtraction 1 | coffeehouse markup
conflict | ? | advisor edits
merge | ? | merge advisor edits

So I think the quality of the mapping is a bit better than it is for
the photography analogy. On the other hand, I think the photography
analogy is more familiar (subjective ;). Is the thesis workflow
familiar enough to help? I dunno. To take that to an extreme, we'd
have a really great mapping if we taught Git using a Mercurial analogy
;). My gut is currently still leaning towards photography to get
folks off the ground, and then just dropping analogies once you get to
conflicts and merges. But I have no data to back that up.

[justbennet]

This is also one of those things that they warn us about where, if one explanation fails, try a different one. I sort of like this one because it will map better to the way the actually use it later. We never explain that individual files have checksums for their versions, too, and those differ from the overall ID (at least that's what I infer from the output of diffs of files where the IDs aren't the IDs of the commit). Part of the point was to try to bring the analogy back a little closer to what people will work on.

For younger, modern people, maybe the group photos are better, and I don't know about you, but I would surely like to modify the person standing to my right in the last group photo and commit him. ;-)

[wking]

On Fri, Apr 22, 2016 at 05:05:31PM -0700, justbennet:
“We never explain that individual files have checksums for their
versions, too, and those differ from the overall ID (at least that's
what I infer from the output of diffs of files where the IDs aren't
the IDs of the commit).”

Yeah, that's probably not going to be part of any analogy ;). And
that is what the IDs are for:

$ git show d83a19f
…
diff --git a/02-setup.md b/02-setup.md
index 1765139..720fdbe 100644
--- a/02-setup.md
+++ b/02-setup.md
…
$ git ls-tree d83a19f | grep 02-setup.md
100644 blob 720fdbead3eb4ed9d39ce9db6cb86c1f863d18b0 02-setup.md
$ git ls-tree d83a19f^ | grep 02-setup.md
100644 blob 17651392efe93059313b675bd523325c58af3702 02-setup.md
$ git show 720fdbe

---

layout: page
title: Version Control with Git
…

So 1765139 is the abreviated hash for the version of 02-setup.md
before commit d83a19f and 720fdbe is the abbreviated hash of
02-setup.md as of commit d83a19f. This is actually useful sometimes
1, but probably not something we want to talk about in this lesson
;).

[rgaiacs]

@iglpdc any update on this one?

[jenningsdt]

I too was looking at this lesson as part of my instructor certification and have concerns about the tape analogy. I worry that the students of today will not fully appreciate that analogy simply due to lack of experience with the older technology.

Of all the discussion above and in #149, I personally think the photography analogy works best. However, I think it is more like an album of screenshots rather than an album of photos. The narrative could go something like:

"Version control systems start with a base version of the document and then save just the changes you made at each step of the way. You can think of it as an album of screenshots: the album starts with the base document, then you can turn each page to view every change, until you end with your latest version."

[twhitehead]

I personally have switched to an entirely different presentation of git. Here is a link to webinar version I did for our HPC centre. It is similar to what I do in person minus the exercises

https://www.youtube.com/watch?v=meFv-GDTkjE

I've received a lot of positive feedback from people who have used git for class projects and such before, but have only been told to run this command and run that command. I haven't done any quantitative comparison to how well students learn from it relative to the SC lesson though.

I did a follow up as well that focused on the collaborative web-based side (submitting patches, etc.)

https://www.youtube.com/watch?v=i9iG5u36XIY

[twhitehead]

@jenningsdt taking your snapshot idea one more step: 😄

Version control is like a video. A series of snapshots though time. It doesn't just give you the ending, it gives you the story of how the ending came to be.

[jenningsdt]

@twhitehead I like the video analogy!