Git doesn't store patches about git-novice HOT 9 CLOSED

I think that we say that

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.

to make easy for students understand the concepts and because

$ git show

only return the diff (not the hole files).

from git-novice.

Indeed. I can see why you described things the way you did. You don't want to make things overly complicated and bog students down with details that will get in their way of learning.

I'm wondering though if there would be someway to give people a simple mental model without setting them up for confusion later when they try and wrap their heads around (non-fast-forward) merges.

from git-novice.

It's true that Git doesn't store diffs in most cases, but other version control systems (e.g. Subversion) do, so the sentence is not entirely misleading. I think the mental model of "diffs" could be pretty helpful for the novice learner.

from git-novice.

I was thinking of something along the lines of introducing things as git storing a chain of versions (one for each commit) and then noting that because git has each version it can easily compute the difference between any two versions. I am hoping this one step of indirection wouldn't add too much additional mental load.

What you gain from this is it then becomes very easy to see how you go from what "changes did this commit introduce?" to "what changes are between this commit and the one four back?" or even visualizing how your chain could do things like branch and then rejoin. It also agrees very well with the sorts of graphs tools like github and gitlab provide.

from git-novice.

I'm happy to clarify this as long as we don't add any additional complication. If you're going to mention that Git stores the whole file, you should clarify that the repo doesn't grow crazy in size even if you have many versions. This is something that, for some reason, worries people a lot.

from git-novice.

I was wondering about people worrying about the storage as I know I would.

Would it be sufficient to say something like "At this point, some of you will be wondering if git consumes huge amounts of storage storing all these versions. Suffice to say the designers of git thought about this too and designed git to use sharing and compression so this does not happen."

from git-novice.

@twhitehead Thanks a lot for raise this discussion.

Another reason for us keep the "diff thing" is that people can always exchange diffs/patches by email or other system. I know that most people are/will be using GitHub but if the project they need to contribute still using a bug tracker that only accept diffs/patches I think that mention that "git keep a full copy of the files" can make confusion.

from git-novice.

I also don't think our learners are likely to ever do a multi-way merge! I have certainly never needed to do so. Also, some VCSes do store patches, so I think it's a reasonable conceptual model for novices.

from git-novice.

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. Along with other stuff, it covers branching and merging without conflicts.

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.

The second part of this, which was also recorded as a web seminar, focuses on the collaborative web-based side (submitting patches, etc.). It also covers merging with conflicts.

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

from git-novice.