"You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards."
"You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means."
"You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End."
I love git, but simple intros like this hide all the confusing complexity and awkward UI that quickly comes to the forefront when using git for everyday work.
I teach courses on Git, and I couldn't agree more. Many of my students have been told that Git is simple, and they just need to know 10 commands. Or they can think about it like SVN. Or that they should push, pull, and that's about it.
Which has the effect of (a) making them fear Git, (b) making them feel like they'll never figure it out, (c) and convincing them that they're always on the verge of losing data. I've literally had students at the start of my course refer to Git as "that system that makes me lose files."
Once I teach people about Git's objects and data structures, things suddenly become much more obvious to these people. Git becomes less of a mystery.
I'm not saying that Git is easy for people to understand or use, because it isn't. It has a steep learning curve -- one which I think is worth the effort. But I think that it does a disservice to Git newbies to try to summarize all of Git's functionality in a short essay, and then proclaim, "See? There's not that much to learn here!"
Agreed: attempting to teach that git is simple does people a great disservice.
To be very effective and safe using git, you really do need to understand a bit about its inner workings. I find that to be a big weakness of the tool, and it continues to surprise me that it's become as popular as it has. I personally like git a lot, and find it to be very powerful, but it took time and an interest in deep learning to get there.
I can certainly understand that most people might want a simple VCS that's easy to use and makes it difficult to screw up. Git is not that VCS, by any means.
I would be grateful for your course. I've used git now for 3+ years and still don't feel like I understand Git's objects and data structures. Maybe it's because I didn't finish my PhD.
Finishing a PhD gives you bragging rights, but it doesn't make you any smarter! (Believe me, it took me 11 years to do mine... and I've got the bills and emotional scars to prove it!)
I might start to teach courses online at some point, but I'm right now so busy with in-person classes in Israel and China (with a bit in Europe probably happening soon) that I haven't had a chance to consider it. But hmm, maybe...
Meanwhile, see my above reply with some suggested resources to learn about and understand Git. I hope that they'll help.
Do a google video search for a presentation called "Git Happens" (by Jessica Kerr). The presenter does a really good job of digging into the data structures.
I personally think git is simple. That doesn't mean it's easy. The issues listed in the GP comment seem to me mostly social. I think the most common problems with git stem from a more general difficulty in working with a branching, asynchronously developed codebase.
About merges... I think rebase is ridiculously overused, and people should use merges more. Clearly a feature branch littered with spurious merges is bad, but often it seems that this is taken simply to mean that merges are bad, and I get the impression that people go to ridiculous lengths with rebase etc. just to preserve an illusion of linear history even in cases where merging would be better.
I have a whole "Git" category on my http://DailyTechVideo.com/ site, which are some of my favorite intros to Git.
Of these, my particular favorite is Michael Schwern’s “Git for ages 4 and up." Watch this, and suddenly Git will make a ton of sense. Jessica Kerr's talk about Git is a close second; it's remarkable for telling us about how Git thinks about things without showing any code.
One of my favorite tools to use in my Git course is this site:
which graphically shows what happens when you commit vs. change branches vs. rebase. Super cool stuff.
If you go through the two of these, and if you understand them, I think that you'll have about 90% of what you need to then re-read a Git introduction, and have things make sense.
I have to laugh a little at this. You just said, "Go through these 2 tutorials, and try out this tool, and then you'll be able to re-read the introduction and understand it (90%)!" I've learned Source Safe, Perforce, and svn in a matter of hours without having to re-read anything. It's absurd to have to watch 2 tutorials and read an additional book twice to understand something that you should basically already understand. Someone really needs to fix this!
I'm not saying that it's necessarily good that using Git basically requires understanding its data structures. But Git is hard to learn, and often hard to use, and surprises people who use it.
The best solution to this problem, I've found, is for people to learn how Git works. Once that happens, everything else falls into place, and their lives are much easier.
So is it ridiculous that you can only understand the Git documentation and tutorials after you understand the data structures? Yes. But Git isn't going away, and if we want people to succeed with it, then we need to help them to learn it, rather than castigate them for using a tool that they need to use for their work.
given that you teach it in-person, I feel that if you were to take the time to write an essay you would automatically bring up the hurdles and a lot of people would find it useful. why not go ahead! You can summarize/start here if you want, we'll give you feedback :)
You're totally right. I'll add this to the list of posts that I really want to write on my blog. I've got a crazy week coming up, but I hope to be able to push out a few posts after that. (Plane trips to/from China are very useful for catching up on reading, writing, and movies...) Thanks for the encouragement!
> "You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards."
Imagine you clone a repo. So your version is identical. You now add a couple more commits to master. Now, to make them identical again, all you have to do is upload the new commits, and then get his master branch to update to point to the latest one. Makes sense, right? That's a fast-forward.
Instead, what you do is merge your latest commit with the older commit two back, which creates a third commit with identical content to the previous one. That's silly, right? That's why fast-forward instead of merge.
> "You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means."
Rebase is when you take the content from a chain of commits, and make a completely new chain with that same content, just because it makes it look neater. You then change the branch from pointing at the head of the old chain to pointing at the head of the new. That's all it does. The old chain is still there until it's garbage collected a few weeks later (or you tag it to stop it disappearing).
> "You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End."
I'm not sure what the fear is here, so I'm not sure what to tell you. Create a test repository with a few commits and change the hashes below for real ones:
git checkout master # on master, whew
git checkout e34a53 # oh no, detached head
git checkout master # it's ok, back on master, whew
git checkout 343a34 # oh no, detached head
git checkout master # it's ok, back on master, whew
git checkout fe34ee # oh no, detached head
git checkout master # it's ok, back on master, whew
git checkout a567ed # oh no, detached head
git checkout master # it's ok, back on master, whew
I wrote a deploy script for our QA system that checks out the commit hash we want instead of the branch and leaves it in detached head mode. Works awesome. Needless to say our ops guys were not amused and demanded it leave it on a branch. People can be do stubbornly stupid sometimes.
I spent a few weeks working with Git, taking full advantage of the cool history-rewriting stuff it can do that Mercurial still doesn't quite match. It worked, but it required the most arcane syntax I've ever seen.
Then I gave up and went back to Mercurial. It does a much better job with subrepos, and I can actually use it without always consulting a hand-scrawled reference sheet for common tasks.
Took me many steps to finally internalize enough of git internals (still a tiny bit) to start losing fear and discomfort. I find it very similar to learning the semantic of dynamic languages (python: http://www.pythontutor.com/, js) where you need to see the data model evolving next to the main `pointers`. It looks obscure but it's not large. Small things aren't easy but not necessarily complex #hickeyism.
Is this an intro or a summary? Because I don't think there's any easy path to learning git, but there's a path, and it goes through understanding the internals, not memorizing UI idiosyncrasies.
The thing about git is that the internals are sensible and cohesive, whereas the UI is a train wreck. This is the opposite of svn where the UI is simple, but the internals are a train wreck.
The simpler subset is useful for personal or internal projects, however, so it's useful to have it spelled out.
(And BTW my own simple subset is still simpler - no branches, for instance, as it helps people delay merges which IMO they tend to overdo even without branches; also helps people pull and think they "got the changes" without actually running the new stuff. Also, my own understanding of rebases, detached heads etc. etc. is minimal at best and I seriously dislike having to learn that sort of thing and having to keep it in mind.)
This is perhaps too few words to elucidate git. I appreciate that Ms. Cook links to other articles on her own site that go into much greater detail. However, I still think the best self-contained and relatively brief explanation of Git is "The Git Parable."[1]
In fact, the Git Parable specifically addresses this articles approach to teaching git in the introduction:
"Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying."
Makes the 600 words achievement seem less impressive, if you put it in the context of existing git education.
I can't agree with this. The 600 word article explicitly does not simply demonstrate some commands and go "tadaaaa". Quite the contrary, it demonstrates some commands and explains how they work, a very impressive achievement for something so terse.
And here, perfectly illustrated, is a reminder why I don't like using some source code version control systems. I don't want to understand the precise implementation of my source code control system, and I don't personally believe that I should have to for effective use.
I realise this is likely an unpopular opinion, but I would challenge you to reply with justification rather than inevitably downvoting me into oblivion.
One of my software development mentors (a long time mechanical engineer who has done UNIX OS development for 20+ years) often has this as his email signature and I think it's rather apt in this context:
Civilization advances by extending the number of
important operations which we can perform without
thinking about them.
With that said, I'm not advocating complete ignorance of how a version control system "works", I just find the philosophy of "you must learn the internal data formats and workings of this system to use it effectively" more than a bit distasteful.
You might very well be right. It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.
I've never used it, but I've heard that Mercurial offers most of the power of Git, with much less of the pain, and an easier user interface. I'm willing to believe that this is true. I'll even believe (whether it's true or not) that Mercurial does provide a nice abstraction layer, one that allows you to ignore the underlying implementation.
The thing is, that doesn't matter at this point. Many people (including me) have gotten through the Git learning curve and now find it to be fantastically useful. I'm far more productive with Git than I was with SVN or CVS, and I'm not the only one to feel this way. As a result, you now have an ecosystem of tools, tutorials, books, etc. that all build on Git -- not to mention companies such as GitHub and GitLab that supply (relatively) easy-to-use tools and interfaces.
Also: A large part of Git's power stems from the fact that you're always thinking in terms of commits, and where those commits fit on your repository's graph. I'm not sure how you can abstract away from that, even if it's an interesting idea in theory.
A combination of critical mass (among open-source developers and a growing number of corporations), an ecosystem, and a powerful (if hard to understand) data model has made Git the standard nowadays. It's a crying shame that Git is so hard for so many people to get... but I've found that in my own work, the learning curve was more than worthwhile, and has made me more productive.
> It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.
I've been using git for 5 years now, and I don't have a clear understanding of "its innards". I once read an overview of how it works under the hood and have a vague notion of what's going on.
What are the typical use case scenarios where you need to know implementation details to "avoid disaster"?
I can rebase/merge/push/pull/commit just fine while being ignorant of implementation.
Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details?
Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings.
Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details.
Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.
That's why I said it was a "reminder" and not a perfect illustration. Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.
Even then, I personally find Git's interface confusing and inconsistent -- there are various examples of that with how you request help (usage) for various commands.
The only way I can personally tolerate using Git at the moment is via SourceTree or the GitHub web interface.
That's just my personal opinion of course and isn't necessarily a factual reflection of Git itself.
I've used various source code control systems over the years: sccs, perforce, bitkeeper, cvs, svn, bzr, mercurial, and so on to various degrees if that means anything. The one I've finally settled on for personal use has been mercurial, which I've generally found fits my own workflows the best and generally has an interface that seems to work without me having to think about it too much.
Almost every article and bit of material I read on Git advocates the understanding of its data formats to make "effective" use of Git or claims that once you understand those things then you can understand how to use the system.
This perspective has root in Fred Brook's observation "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
With that usage, you don't need to understand the implementation. But in my experience of using Git without really understanding it, there is about a 90% chance of destroying your repository when you try to revert something. I have never had this problem with any other VCS.
I'm sure simple reverting is super easy once you know what you're doing, but you need to know what you're doing.
Well that does look simple, but first of all, it doesn't really revert a commit. It makes a new commit to cancel out the old one, or something. Not intuitive, unexpected results if you don't know what you're doing.
But the situation I got into was when I did something stupid and just wanted to undo it. Let me go back to an hour ago before I screwed up my project. That's not revert, it's reset, but reset only reverts the commit history, you really want reset --hard. And of course you need to be pointing to the right place for this to work, and there are other ways for it to go wrong. It might be hard to imagine if you're at all competent with Git, but trust me when I say you can get yourself into some very frustrating scenarios if you just Google "undo push" and blindly follow the instructions.
Here's another simple scenario: I'm working on a bug, my friend fixes it first and pushes his version. I just want to pull his changes and throw away whatever I was working on. Ok, so I find this: http://stackoverflow.com/questions/1125968/force-git-to-over...
Look how many different methods there are. Look how many warnings of "THIS WILL DELETE ALL UNTRACKED FILES" there are. Why is this necessary? I could rant for a while longer, but this stuff is so incredibly unfriendly and frustrating to newcomers. I don't want to think about this stuff, I just want to go back to the code.
And yet every time I looked at the docs for git in the two or three years I was using it heavily I happened upon these dire warnings about destroying and losing work. I understand why git is so powerful, and to manage something as complex as the Linux kernel that power matters.
For what I do for a living it isn't, and Mercurial is a nice alternative that for whatever reason doesn't have any scary warnings in the docs about how I can destroy everything if I revert or rebase inappropriately, or whatever. Mercurial also seems a lot more aggressive about checking if I'm doing something stupid or dangerous and warning me about it, whereas git takes more of the traditional Unix "You Asked For It You Got It" philosophy.
Again: I understand why this is the case, but it's not the optimal tradeoff for me.
I think calling the basics of the data model its 'precise implementation' is excessive. It's like complaining about having to learn the precise details of your display server because someone tries to explain to you how windows in a typical window manager work. The underlying model of git is not terribly complicated, is distinct from (but maps reasonably closely to) its implementation, and it makes understanding all the operations on a repo and working directory a lot easier, as well as making it easier to google for help if you get stuck or want to do something new.
Git hides a lot of complexity, instead exposing an unintuitive set of commands to control your data. Multi-user distributed version control is a very complicated problem to which there will never be a simple solution. If you are willing to sacrifice some features, there are probably simpler solutions that would be more fitting with your work process.
I agree. Everyone should do their own cost benefit analysis. Git has a set of features and costs that make it highly suitable for some combinations of organization and project and not so suited for other combinations. There is no silver bullet.
This is a cool essay! It's very approachable. I would really like to understand git under the hood one day, but I'm intimidated by how much it does with such a small memory footprint.
My group project partner and I were having the toughest time with git last night. I thought we were all ready to walk out the door and then we ended up monkeying around with it for an hour and a half.
They're great for people who know the names of all the git commands but who are still thrown off in really basic situations, ie 'Is it merge master? Merge origin master? Merge origin/master? Why does it say already-up-to-date?'
and it just undoes whatever you just did. There seems to be a way to undo pretty much anything, but I usually end up googling and deciphering the likes of
git reset HEAD hard -f --now origin/master --no-rebase %${%&`+'${`%&NO CARRIER")
Then when that goes wrong, you're in real trouble and left scratching your head at git's error message.
Hmm, the reflog usually (always?) provides all the info you need to undo the last action. I wouldn't be surprised if it were possible to build a "git undo" command on top of that. The fact that no one has yet done so is a great illustration of your point, though.
The reflog just lets you undo commits (whether created by `git commit` or rebase or merge or whatever), while actions like `git reset`, `git checkout`, `git add`, `git gc`, and `git rm` cannot be undone with the reflog.
There is some subset of all VCS software that contains the handful of commands that 80% of coders need 80% of the time. Conceptually, these commands are very nearly isomorphic for individuals making changes to files by themselves.
These paragraphs do indeed cover those commands for git, although I can't see why this presentation is particularly useful, even for a beginner. It's just a condensed HOWTO that doesn't actually explain what it's doing.
Newcomers would be better advised to sacrifice the 30 minutes and read the first three chapters of the storied git book: http://git-scm.com/book/en/v2.
As a new user of Git, I cannot support this comment enough. The Pro Git book is a fantastic resource that cleanly and concisely outlines the command AND the conceptual framework upon which Git operates.
I strongly recommend that all new users read at least those first 3 chapters, but also the very useful chapters on using GitHub - a website that I have personally found extremely unintuitive to use.
The essay seems to encourage the realisation that nothing really special is happening under the hood, which in my view is important for people who are learning to use git.
For six hundred words, I think it does a good job.
And then skip ahead and read chapter 10: git internals. This was really helpful for me to understand the fundamental concepts of git and why it is designed the way it is.
I'm an SVN user, and I'll have to move to git some day, but it's not winning any points for me :-( . I got bit by it recently. I had cloned a repo, and then a few weeks later, did
% git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
I assumed the working copy was up-to-date, as git states.... but alas, no. I had to do a "git pull" to get the latest changes. Why doesn't git tell you that your copy is out of date?
Git does not check with the remote unless you tell it to. So "origin/master" points to what master on origin pointed to the last time git contacted the origin remote.
To have git contact the remote again, you can do "git fetch origin" (or just "git fetch"). Then git will tell you your copy is out of date compared to origin/master, if there's been commits on origin since.
If you commit things, then your copy will be ahead of origin/master, so origin/master is what is out of date and you need to git push:
~/dotfiles % git status ✓✗ master:c024cb4 - dotfiles
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
It's up to date with origin/master, which is the local copy of the remote master. 'git fetch' updates those local copies. 'git pull' does a fetch and then merges origin/master into master.
It makes sense when you consider that there are other ways that origin/master could be updated. You could apply commits that someone emailed you (a common workflow in the Linux kernel that git was designed to support), or someone could push commits directly to you over SSH or the filesystem.
`git fetch` and `git push` talk to the remote(s) (if any) that you have configured. Most (all?) other commands are local operations. `git status` compares your working copy to your local `.git/` database.
If you want `git status` to compare `.git/` with the state of a remote, you must first `git fetch` the state of a remote into your local `.git/`. And you may have multiple remotes, as well...
I've used git for years after having spent years with SVN. no one taught me SVN and never really read much documetation. It was so simple and straightforward. Git introduces a lot of new power and features, but nowhere near the cost increase of the learning to use it. FWIW, I always hoped Mercurial would win. It's at near feature parity with git, but is far easier to use.
We're definitely staging a comeback. Mercurial's development is lively and interesting, and with the backing of the likes of Google, Facebook, Mozilla, and Atlassian, we definitely are seeing lots of good stuff in hg.
Because git lied to you. When it says "you are up-to-date with origin/master" it did not actually check that it is up to date with the code on the origin. This is one reason why Git is inhumane. It's reasonable that it didn't check with the remote repo, but its misleading use of the word "origin" does not help new users.
> It's reasonable that it didn't check with the remote repo, but its misleading use of the word "origin" does not help new users.
But 'origin' is just the name of the remote repository, not something hardwired into git, right? (Maybe this response is undercut by the fact that it is the default name.)
As others have said, you'd need to do 'git fetch' first before 'git status' would report a difference.
The reason git doesn't do this automatically is because, in its simple model, it doesn't waste time trying to connect to the remote 'origin' or any other remotes you may have configured every time you do 'git status', which is most often used to check what you've modified locally.
I can understand why this would be jarring coming from SVN, where you always want to be checking against the remote/server. Since git has a copy of all history locally, remotes are de-emphasized compared to centralized VCSs.
Git maintains a local copy of remote branches (to some extent, I'm not sure of the mechanics) and I believe you can cause it to update that with 'git remote update', 'git fetch' and a couple of other tools.
If you have a branch called "master", whose HEAD is currently "a4300d840a4d01767cb2e768e51f7e88cb40e8cb", for example, all that means is that there is a text file called ".git/refs/heads/master" which has the contents "a4300d840a4d01767cb2e768e51f7e88cb40e8cb".
That's all there is to a branch. Do:
cat .git/refs/heads/master
in any git repo you have on your machine and see (compare it with 'git log')
If you have a remote branch that points to the same commit, all that means is that there is a text file called ".git/refs/remotes/origin/master" which has the contents "a4300d840a4d01767cb2e768e51f7e88cb40e8cb". Again, that's all there is to a remote branch.
Well, ok, there's also an entry in your ".git/config" file that gives the URI for "origin" (or whatever you've named your remote server; origin is the default).
All these files are just text files. Have a look at them in your favourite text editor (or with less or whatever).
Same reason your OS won't upgrade your packages unless you update the package list from the repository. I can empathize with the confusion coming from SVN.
I think it's safest to assume that any `git` command that doesn't by necessity make a request to the remote repo (like `git {fetch,pull,push}` and others) does not make a request to the remote repo.
Fast-forward 5 years into using Git, I learned that git add and git commit is all you need to know to get started. I learned everything else, on the job and by need.
- git push when I needed to take work to Github
- git checkout when I needed to move between branches
- git merge when I needed to merge someone else work into master
- git cherry-pick I needed this to take commits from a non-fork to my project
- git bissect Debugging a bug introduced between releases
I also learned to use Github tools, SourceTree, the Command-Line and Bitbucket. If you want to learn git, just make a commit. Everything else will be mastered down the road.
For me, the hardest thing about learning Git is the lurking feeling that I have to learn it because it has become an unavoidable fad, not because it is the best approach to version management for most common use-cases.
I think your attitude is completely reasonable, and I'm with you on your skepticism. However I am pleasantly surprised that, for once, a software fad lines up with what is actually technically superior. Linus knows how to design software correctly.
The page is just pure white for about 30 seconds before it loads for me. (Gentoo Firefox on Linux.) I don't know why but all the items on the page are positioned off page with "visibility: hidden".
Anyway, in case the author sees I thought they might want to know. And if it doesn't load for someone here, wait 30 seconds and it probably will.
I can see in the console your fonts are failing to load. Perhaps this is causing the issue?
"The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something."
Anyone know of a point and click graphical tool for git? I've seen the branches and merges from the console but if I simply want to take git to a specific commit hash, it can easily devolve into hours of research.
I believe the problem here is that even though there are only a finite number of choices (less than a dozen in everyday life) representing what I want to accomplish, there are countless ways of getting there with commands. I just don't remember having these kinds of problems with svn, so I think the difficulty is not conceptual, but due to a poor mapping between the concepts and the interface.
I'm thinking something like Apple's Time Machine, where you click a commit and the repo shows up on the desktop as a mounted drive. We could use ordinary tools to edit the image and when it's unmounted it becomes a new commit (or something along those lines).
I like SmartGit enough that I paid $80 for it (despite the fact that it seems weird to pay money for dev tools these days). You can download it and use it free for non-commercial use, though.
I'm reasonably comfortable with the git command-line tools, but for keeping the simple things simple I really do like an integrated all-in-one visual diff/VCS client program and SmartGit is the best one I've used for git.
SourceTree (mentioned by fsk) is kind of a trainwreck on Windows, in my experience (moving to SmartGit was the result of me getting fed up with SourceTree and looking for something not as frustrating). From what I understand the Mac version works better, though I haven't used it. While the UI is quite nice to start, the Windows version of SourceTree tends to soft-hang a lot (goes into non-responsive states it eventually recovers from, but will hang for like 30+ seconds at times) and it has a lot of weird issues with multi-monitor setups (it'll sometimes randomly jump to the other monitor during pane resizing and such).
git comes with `gitk` and `git instaweb` out of the box; both of these are point-and-click graphical tools that show you branches, merges, and specific commit hashes.
I think what you're looking for here
> you click a commit and the repo shows up on the desktop as a mounted drive. We could use ordinary tools to edit the image and when it's unmounted it becomes a new commit
is basically `git checkout -b newbranch 80238ec` followed by `git commit -a`.
Nope, git can be initialized in directories with files in them.
➜ ~ mkdir test1
➜ ~ cd test1
➜ test1 echo "hello" > hello.ttx
➜ test1 ls
hello.ttx
➜ test1 git init
Initialized empty Git repository in /home/david/test1/.git/
➜ test1 git:(master) ✗ git status
On branch master
Initial commit
Untracked files:
(use "git add <file>..." to include in what will be committed)
hello.ttx
nothing added to commit but untracked files present (use "git add" to track)
➜ test1 git:(master) ✗
"You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means."
"You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End."
I love git, but simple intros like this hide all the confusing complexity and awkward UI that quickly comes to the forefront when using git for everyday work.