git lecture
Merge request reports
Activity
added 2 commits
This one could be nice: https://mermaid.js.org/syntax/gitgraph.html
aka:
```{mermaid} gitGraph commit commit branch develop checkout develop commit commit checkout main merge develop commit commit ```added 25 commits
-
016fb2e0...7e870b7b - 10 commits from branch
main - 7e870b7b...8cf889b9 - 5 earlier commits
- 89db8f6c - add content for branches, best practices and remote repos
- 29268a01 - Add motivation and first steps
- 83a01de0 - Add recommendations to best practices
- 84e4580f - Fix typos
- 63a057ac - Add fragments for ordered animation
- 3c3f472c - reorganize slides and add content
- c685b28e - Restructuring of branches sections
- 1a916408 - add gitlab merge request screenshot
- 7a3dc622 - Add new CSS selector for tiny fonts
- f475f35f - Revise section on remotes and shotgun buffet
Toggle commit list-
016fb2e0...7e870b7b - 10 commits from branch
The lectures is now complete, i.e., all content we want to cover is there. The slides likely need some final polishing, but we wanted to ask for general feedback first. @m300827 and @k202160, would you be willing to provide feedback as you are likely building on this for "git advanced"?
But feedback by @k202134 and @m300564 is also welcome
added 1 commit
- 192cd066 - Fix alignment on slides without bulleted lists
- lectures/git/slides.qmd 0 → 100644
51 git config --global user.name "Your Name" 52 git config --global user.email "youremail@yourdomain.com" 53 ``` 54 55 ## Hands-on Ssssion {background-color=var(--dark-bg-color)} 56 57 1. Configure the username and email adress in your local git client 58 2. Initialize an empty Git repository 59 3. Create a file and add it to the repo 60 3. Change the file, inspect the differences, and commit the changes 61 62 :::{.info .smaller} 63 On Levante: `module load git` 64 ::: 65 66 # Branches 
A slide or two on commits would be good before the branches are introduced. The branch slide mentions the existing hash, but the concept of the sequence of commits with hashes is not really introduced beforehand. I remember watching a presentation long time ago, that introduced the concept of git as tracking changes instead of versions in svn and _newer_7-revised-AB.doc . I think that would be good to do here as well... Also for concepts like merging branches and rebasing. And then there's hashes instead of version/change-numbers...
-
The more I look at it... I like the slides that are there. I think what's really missing is more intro.
There's a why version control but not what is version control.
There's the basic "keep track of edits on a file", then there is the concept of "a consistent status across a directory hierarchy" (good luck of tracking consistent code versions with file.py.newer_3), and then there's "tracking changes, not versions" mentioned in the first part of this comment.
-
that introduced the concept of git as tracking changes instead of versions in svn
What? Whoever did this, introduced git incorrectly. As the Pro Git Book says:
Snapshots, Not Differences
The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These other systems (CVS, Subversion, Perforce, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as delta-based version control).
Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.
-
Interesting - I keep learning with this lecture... Here's one of the old sources (mainly referring to HG vs svn, but taking HG as an example of distributed version control like git) https://www.joelonsoftware.com/2010/03/17/distributed-version-control-is-here-to-stay-baby/
So, we have a different story than the one I had in mind, but we should probably nonetheless tell it...
-
I've tried to dig a bit more into the inner workings of mercurial (which I'm not very familiar with), but their behind the scenes seems like HG is indeed a bit more on tracking changes. On the other hand, git also has packfiles which do some form of delta-encoding under the hood. The difference between HG and git might be that HG seems to treat their filelogs as immutable whereas git explicitly keeps the freedom to repack objects during garbage collection, only keeping the interface to read and write snapshot-like objects stable.
Anyways, probably it's not too important for this lecture to distinguish if the system is tracking changes or snapshots. And during normal work one will often switch between the views: e.g. while the git objects (blob, tree, commit) are snapshots, we often also look at differences (
git diff,git cherry-picketc..) but we are also interested in the snapshot (git switch,git checkoutetc...).So to try to get back to the motivation, maybe we should note that it is useful to have:
- an ordered sequence of snapshots of the work over time
- mostly to get back to older versions if something screwed up, much like
diss_1.tex,diss_2.texetc... - it's often useful to have those snapshots of a whole directory and not only a single file
- mostly to get back to older versions if something screwed up, much like
- a way to handle changes between snapshots
- to review what has changed
- to redo a change on some other version (e.g. Alice did a lot of things but Bob wants one of the changes)
It's a good idea for whatever we use to keep track of changing code / text / etc... to be able to handle snapshots, sequences of snapshots and differences between snapshots. Thus we might want to use a tool like
git,hg,svn,cvs(or maybercsif we don't like directories... :-)) - an ordered sequence of snapshots of the work over time
-
I couldn't really stop digging into this snapshot-based vs patch based version control system theme. I now came across
darcs(which I had heard of earlier, but never actually looked into). So apparentlydarcsis a truely patch based version control system, its internal state is a set of patches, not a sequence of snapshots. An interesting consequence seems to be, that there are no "merge"-commits (because a merge is just the set union of both patch sets), which means that one won't end up in different states if commits are merged or rebased in different orders or by different people. So it seems like I'll have to dig deeper intodarcs.Also the
darcspeople have:
-
What I'm still struggling with a bit is the question of the homework. So far, there's no real need for them to do any work outside the classroom. That also means there's less time they'll spend learning things, and we are not really forcing them to learn to look up things themselves. Not saying I'd have a good idea what to give them as homework. Maybe some kind-of-messy three-branch gitlab repo that they have to fork, and then fix a couple merge conflicts to get everything into the main branch? Feels like that would be a pretty realistic real-world situation, but also not really encouraging to use git. However they'd run into that setup sooner or later anyways...
-
I'd suggest them to have to think about what of their actual should be version-controlled by git, create corresponding repos and put stuff there?
They could hand in a txt file with a few links to the new repos, some argumentation why it is sensible to do version control for this, and, additionally, some counter-example from their work, like ... sim-output, ...
-
Privacy is why Tobi came up with the git-repo-creation-script. This basically would allow us (the lecturers) to see their homework while keeping it hidden from the other participants. And I think that the discussion of the homework could even happen on the meta-level, i.e., what types of files do you want to track, without showing the actual content. Though it is still good for them to submit something so they don't improvise on the spot ;)