Mental model change to versions and computed differences #150

Open
wants to merge 1 commit into
from

Projects

None yet

7 participants

@twhitehead

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

@twhitehead twhitehead Mental model change to versions and computed differences
* Git does not store a series of patches (unlike other systems)
* Series of patches mental model confuses non-fast-forward merges
af61d20
@jiffyclub jiffyclub commented on the diff May 27, 2015
01-basics.md
@@ -20,11 +20,11 @@ automated version control is much better than this situation:
We've all been in this situation before: it seems ridiculous to have multiple nearly-identical versions of the same document. Some word processors let us deal with this a little better, such as Microsoft Word's "Track Changes" or Google Docs' version history.
-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 a tape: if you rewind the tape and start at the base document, then you can play back each change and end up with your latest version.
+Version control systems keep track of a chain of document versions starting with a base version. This is done in an efficient manner so as to not consume large amounts of space. Given two versions, such as the current and previous or the current and the one last week, version control systems can easily compute the difference to show us what has changed.
@jiffyclub
jiffyclub May 27, 2015 Member

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
rgaiacs May 27, 2015 Contributor

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
daisieh May 28, 2015 Contributor

+1

@jiffyclub jiffyclub commented on the diff May 27, 2015
01-basics.md
-Once you think of changes as separate from the document itself, you can then think about "playing back" different sets of changes onto the base document and getting different versions of the document. For example, two users can make independent sets of changes based on the same document.
+The idea of the differences between two documents is extremely powerful. Once we think of the differences as separate from the document itself, we can then think about "playing back" different sets of changes onto the base document and getting different versions of the document. For example, two users can make independent sets of changes based on the same document.
@jiffyclub
jiffyclub May 27, 2015 Member

I would also rephrase this to remove the focus on diffs. Maybe instead something like "A VCS stores every version of a document so it's always possible to retrieve a particular version. Multiple users can even modify the same document in parallel without interfering with each other."

Though I'm actually on the fence about that second sentence because I feel like that promise is only fulfilled if we talk about branching.

@daisieh
Contributor
daisieh commented May 28, 2015

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
Member

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
Member
wking commented Nov 14, 2015

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
Contributor
daisieh commented Nov 14, 2015

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
Member
wking commented Nov 14, 2015

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
Contributor

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
Member
wking commented Apr 22, 2016

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
Contributor

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
Member
wking commented Apr 23, 2016

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
;).

@iglpdc iglpdc was assigned by gvwilson Jul 31, 2016
@rgaiacs
Contributor
rgaiacs commented Aug 27, 2016

@iglpdc any update on this one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment