Thanks for sharing. I too agree on this: "... Git is complex is, in my opinion, a misconception... But maybe what makes Git the most confusing is the extreme simplicity and power of its core model. The combination of core simplicity and powerful applications often makes thing really hard to grasp..."
If I may do a self plug, I had recently written a note on "Build yourself a DVCS (just like Git)"[0]. The note is an effort on discussing reasoning for design decisions of the Git internals, while conceptually building a Git step by step.
While this is nice, I think it should be emphasised that the blob-tree-commit-ref data structure of git is not essential to a DVCS. One of the disadvantages of everything being git is that everyone can only think in terms of git. This makes things like Pijul's patch system, Mercurial's revlogs, or Fossil's sqlite-based data structures more obscure than they should be. People not knowing about them and considering their relative merits has resulted in a bit of a stagnation in the VCS domain.
What makes it hard is that it’s taught wrong. All this pull/checkout/commit/push whereas for me it took a long time to discover that fetch/rebase/show-branch/reset/checkout —amend, and especially the interactive -p variants, are the core tools that really make it a pleasure to use. They give you flexibility and let you write and rewrite your story, whereas the commands you’re introduced with provide no control to the user. It’s remarkable the number of users who think you can’t rewrite a Git branch.
From my limited knowledge (mostly based on jneems article series[1]), I think Pijul is more powerful, but for the same reason also considerably more difficult to understand than Git.
In particular, Pijul supports (and depends on) working with repository states that are, in Git terms, not fully resolved. In addition, those states are potentially very difficult to even represent as flat files (see e.g. [2]). Git is simpler in that it mandates that each commit represents a fully valid filesystem state.
That said, I still think Pijul might have a place, if it turns out that it supports superior workflows that aren't possible in Git. But the "VCS elitism" would probably become worse than it is today.
I really like the way Pijul "thinks". Unfortunately, I can't see myself using it (or Fossil, for that matter) for anything except toy code, because I have contract requirements to store everything in GitLab.
Having written my own git client, I can tell you that "the most complicated part will be the command-line arguments parsing logic" doesn't go away. I wouldn't be surprised to wake up one day and find someone published a proof that NP != P, and the proof involved trying to parse the git command line.
Those familiar with Mercurial will surely notice it is, in fact, a port of a Mercurial’s interactive commit functionality, previously a separate extension called crecord.
It is indeed a great (and time consuming approach). Other VCSs have gone a little further than Git though, simplifying their workflows or the GUIs and CLI commands to make their use more intuitive like https://www.plasticscm.com/ and others.
Just be aware that it is a good start but isn’t as complete as the command list would indicate - runs up to about the point of index files, so not quite at ‘git add’.
I'm just written a simple git dumper tool (https://github.com/owenchia/githack) a few days ago. Learn by doing is a very good way and I really enjoy it.
This is such a great tutorial to learn Git from the bottom up. I always thought the "back end" part of the Git is pretty complex but this tutorial makes it look so easy.
This is simply excellent. I already know some basics of the internals of git at a conceptual level but this tutorial makes the knowledge so much more concrete. Wonderful.
Doing a search on HN for "write your own" returns a lot of answers, including 'Ask HN: “Write your own” or “Build your own” software projects' https://news.ycombinator.com/item?id=16591918 from a year ago.
I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again.
So I think: there must be a better way.
I have often thought about implementing a VCS. The idea behind one doesn't seem particularly complex to me (certainly it's simpler than programming languages). If I did I would quite probably use WYAG as a starting point. My first step would be to define the user's mental model -- i.e. what concepts they need to understand such that they can predict what the system will do. Then I would build a web-based UI that presents the status of the system to the user in terms of that model.
Yeah, I too don't really understand git. It seems that it was developed without any concern for affording a good mental model of its operation to its users, and thus it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down. I know I could build a mental model of it if I put enough time into it, but who wants to do that when there's actually useful things to do? So instead when I have to use it to contribute to open source projects I have a sheet of notes with incantations to cover the specific things I've had to do with it in the past.
To provide an alternate viewpoint, I have never had trouble with Git. I’m a bottom-up how-does-this-thing-work sort of person so when I first started using Git, I sought to understand how it worked. That part of Git is pretty easy to understand. Knowing that made its CLI a lot easier to grok. Of course, at the time I was having to use ClearCase at work and Subversion on the side so Git, IMO, was a vast improvement to either of those tools.
git is to version control systems as vim is to text editing or dwarf fortress is to god sims.
(dear everyone here and elsewhere recommending git incantations "but of course you have to know what you're doing": if you regularly have to take a backup of your working area before interacting with the vcs, because the interaction may do things you did not intend from which the simplest way back is to reset hard and start over, I humbly suggest that the vcs has failed in its primary purpose)
I'm in the same boat.
I could teach subversion in 1 hour and people would get it.
I can't teach git in a whole week. So in the end my students use the same 5 commands.
I'm like you. I use SourceTree to get a 'visual grasp' on what I find to be the noise of git commands.
However, if you're into command line, you can try fossil: it's got lots going for it.
Your idea of a "user's mental model" might land you into trouble though, because all of us come from different backgrounds (subversion, SSafe, git, HG...) and they all maddeningly redefine terms in different ways (eg branch, forks, commits, checkout).
Look for a video on YouTube called Git Happens. I've found it fairly effective with my coworkers. It doesn't go over the command syntax, but instead dives into a logical overview of the underlying data structures.
I'm not much better. I knew SVN inside out. I've read up on git internals, poked around with them, but eventually forget it all because 99% of the time I only use the same five commands. It's a real iceberg, Pareto principle piece of software for me.
[+] [-] sransara|7 years ago|reply
If I may do a self plug, I had recently written a note on "Build yourself a DVCS (just like Git)"[0]. The note is an effort on discussing reasoning for design decisions of the Git internals, while conceptually building a Git step by step.
[0] https://s.ransara.xyz/notes/2019/build-yourself-a-distribute...
[+] [-] jordigh|7 years ago|reply
[+] [-] linkmotif|7 years ago|reply
[+] [-] s4vi0r|7 years ago|reply
[+] [-] seleniumBubbles|7 years ago|reply
People in this thread might also appreciate this essay: https://maryrosecook.com/blog/post/git-in-six-hundred-words
And the more expanded version: https://maryrosecook.com/blog/post/git-from-the-inside-out
It really helped me comprehend Git enough to start understanding the more complex work flows.
[+] [-] JustSomeNobody|7 years ago|reply
[+] [-] dakra|7 years ago|reply
[1] https://jwiegley.github.io/git-from-the-bottom-up/
[+] [-] asdkhadsj|7 years ago|reply
[1]: https://pijul.org
[+] [-] nemetroid|7 years ago|reply
In particular, Pijul supports (and depends on) working with repository states that are, in Git terms, not fully resolved. In addition, those states are potentially very difficult to even represent as flat files (see e.g. [2]). Git is simpler in that it mandates that each commit represents a fully valid filesystem state.
That said, I still think Pijul might have a place, if it turns out that it supports superior workflows that aren't possible in Git. But the "VCS elitism" would probably become worse than it is today.
[1]: https://jneem.github.io/merging/ [2]: https://jneem.github.io/cycles/
[+] [-] thomascgalvin|7 years ago|reply
[+] [-] chrislo|7 years ago|reply
It also takes a ground-up "build it yourself" approach and has tons of interesting detail.
[+] [-] driusan|7 years ago|reply
[+] [-] Jupe|7 years ago|reply
https://git-man-page-generator.lokaltog.net/
:)
[+] [-] andrewshadura|7 years ago|reply
https://github.com/andrewshadura/git-crecord/
Those familiar with Mercurial will surely notice it is, in fact, a port of a Mercurial’s interactive commit functionality, previously a separate extension called crecord.
[+] [-] MordodeMaru|7 years ago|reply
[+] [-] Milank|7 years ago|reply
The only problem now is the time.
[+] [-] speter|7 years ago|reply
There is a video course as well: https://www.git-tower.com/learn/git/videos#episodes
[+] [-] mcbain|7 years ago|reply
[+] [-] Chia|7 years ago|reply
I'm just written a simple git dumper tool (https://github.com/owenchia/githack) a few days ago. Learn by doing is a very good way and I really enjoy it.
[+] [-] bibyte|7 years ago|reply
[+] [-] zadwang|7 years ago|reply
[+] [-] blastbeat|7 years ago|reply
[+] [-] dprophecyguy|7 years ago|reply
Please point them out here
[+] [-] inetsee|7 years ago|reply
[+] [-] vkaku|7 years ago|reply
[+] [-] ansible|7 years ago|reply
[+] [-] Vogtinator|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] cabalamat|7 years ago|reply
So I think: there must be a better way.
I have often thought about implementing a VCS. The idea behind one doesn't seem particularly complex to me (certainly it's simpler than programming languages). If I did I would quite probably use WYAG as a starting point. My first step would be to define the user's mental model -- i.e. what concepts they need to understand such that they can predict what the system will do. Then I would build a web-based UI that presents the status of the system to the user in terms of that model.
[+] [-] AnIdiotOnTheNet|7 years ago|reply
[+] [-] js2|7 years ago|reply
http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
To provide an alternate viewpoint, I have never had trouble with Git. I’m a bottom-up how-does-this-thing-work sort of person so when I first started using Git, I sought to understand how it worked. That part of Git is pretty easy to understand. Knowing that made its CLI a lot easier to grok. Of course, at the time I was having to use ClearCase at work and Subversion on the side so Git, IMO, was a vast improvement to either of those tools.
[+] [-] tsukikage|7 years ago|reply
(dear everyone here and elsewhere recommending git incantations "but of course you have to know what you're doing": if you regularly have to take a backup of your working area before interacting with the vcs, because the interaction may do things you did not intend from which the simplest way back is to reset hard and start over, I humbly suggest that the vcs has failed in its primary purpose)
[+] [-] neals|7 years ago|reply
So I guess 97% of users don't really get git.
[+] [-] elviejo|7 years ago|reply
[+] [-] cmroanirgo|7 years ago|reply
Your idea of a "user's mental model" might land you into trouble though, because all of us come from different backgrounds (subversion, SSafe, git, HG...) and they all maddeningly redefine terms in different ways (eg branch, forks, commits, checkout).
[+] [-] derekp7|7 years ago|reply
[+] [-] rezeroed|7 years ago|reply
[+] [-] rsp1984|7 years ago|reply
I guess I would be lost as well just using the command line.