some of the git's naming was also not intuitive for me, For example, calling the scratch area "index". I didn't seem to have to learn perforce, cvs or svn's internals to use them fluently.
but I guess it's a bit difficult to change the current situation. git has become the most common choice. And once the mental model has built, it's not that difficult to use, admittedly I only use a few very common commands.
you know the challenge won't be building the version control. for mass adoption, you need a github-like platform.
For me this was (and is) the main source of "what is this and how do I use it" problems. Git is supposed to be an advanced tool to make snapshots of a folder, save them in a tree structure with multiple leaves, combine or even modify them, keep a copy remotely, etc.
So, you are probably expecting to find a "save" command, an "upload/download", maybe a "combine snapshots", and for more advance tools an "edit history". But instead you have "commit", "push/pull", "merge" and "rebase". Those are less intuitive (specially for non English speakers) so you end using only the few ones someone told you to use.
Once I realized what "fixup" was and how to use it I can't stop using it.
Git model is no so complex, the naming is, so it's like learning a whole new language and it takes time.
I think this is the real problem. Git is actually really simple. The mental model is not even difficult - you can describe it in a sentence or two.
* Each commit is a snapshot of your code at a certain point. Like making a copy of your project and renaming the folder (but stored more efficiently). Commits also include metadata to say which previous commit(s) they are based on.
That's it.
All the difficulty comes from figuring out what the hell all the badly named and confusing commands do. As you mentioned I think "the index" is probably the worst - why not "draft commit" or just "draft"? That's what it actually is. It's so bad people even invented an unofficial name for it ("staging area").
It's not the only one. "Commit" is a pretty bad name in itself. It's not even a noun - "snapshot" would have been better.
And there's the commands... Look up how many different things `git checkout` does, or `git rev-parse`. And don't ask me how many times I've googled "git delete remote branch".
They did add `git switch` so I'm mildly hopeful that at least some people care.
> * Each commit is a snapshot of your code at a certain point. > That's it.
Unfortunately, it's a bit more nuanced than that. What you described is only git's storage format. Git operations and UI unfortunately isn't consistent with that model. Take for example, interactive rebasing. By your definition, if we delete a commit, the subsequent commits should remain unchanged - because commits are only snapshots after all. But that isn't what happens. The change introduced by that commit gets deleted from all subsequent commit. Commits are treated as diffs here.
Git UI switches between snapshot and diff model quite often. Merges and rebases are all patch operations. Novice users can get away with being oblivious to this change for most operations till merges. But rebases require you to be aware of it. Even for experienced git users, large multi-commit interactive rebases are hard because git simply hides all the nuances of patching (you are better off rebasing in small chunks). This becomes immediately clear when you use a tool like quilt or stgit. In my opinion, this is something that prevents beginners from going beyond clone-commit-merge workflow and being able to create beautiful commit history like that of the kernel.
Being simple and being easy to use are two different things. Brainfuck is simple, but writing a hello world is hard. Python is superficially easy at the beginning, but I wouldn't call it simple. There is a balance to find between simple and easy, and git is on the simple side, at the cost of the easy.
I don't claim the git CLI is always logical. But you seem to complain that there is one.
1. Most terminals have command history, so if you're really typing the same thing over & over & over & over... just use that? 2. Even if that's not the case, bash/batch/powershell scripts to automate things? 3. Most IDEs nowadays have pretty solid git integration so if you're wanting to click things, there's that.
https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.h...
We need to teach tools like git (and some editors!) as their own thing, completely separate to programming languages. Not "now we've written some code, let's put it in git" but "here's a tool called git, let's show how it works with some text files"
Honestly - you spend 20 minutes with someone teaching them that git only stores diffs and how that actually works and they leave much more confident and willing to experiment on their own.
A plain text TODO list is absolutely perfect for this, because a merge conflict between two steps on a numbered list is completely intuitive and resolvable. "I've got two 4)s now!" "What's the fix?" "I guess one needs to become 5)?"
(The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)
...except that isn't what git stores (as loose objects); in fact it's one thing that distinguishes git from earlier tools. See eg https://medium.com/@paritosh90/understanding-git-internals-c...
I think it's useful to understand how git actually stores objects as blobs and trees, but the mental model of "commits are diffs" is still useful. Commands like git-cherry-pick really make the most sense when thought of in terms of diffs. Internally, for a command like that, git is taking the diff and applying it, anyway, so the model isn't really that inaccurate.
I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict.
In that situation, it's important to keep in mind there's three separate tree-like things: the actual working tree; the index; and HEAD. And git status shows nothing more or less than the diff between the working tree and the index. I've gotten myself out of some confusing situations just by reminding myself of that and thinking things through very carefully.
I also don’t like the `command <subcommand>` syntax but I’m not sure any naming approach can make life easier/harder for people unfamiliar with the language.
You do réalise that the author of git is not a native speaker of English?
When I try to use git for personal projects (because everyone uses it and I'd like to learn it) and I really am struggling sometimes to get even the simplest workflow working as a single person. I can't even imagine how it would work when having multiple people work together.
Perforce on the other hand when it is set up for pessimistic locking, that was interesting when I had to use it in a team setting and trying to work from home 14 years ago.
edit: start at 3:00 mins in
Makes it very difficult to trust anything he says or does in the following segment.
Then it kept going, and going, and I started to feel fear.
I think I'm going to use this when someone tells me "git is easy"
Edit: I think the video was a joke, I don't find that list anywhere. Very funny anyways.
Maybe a plain English tool that just lets you click through menus to dictate what you want to do. No Git lingo whatsoever. Very rough examples below:
1) "I want to save my progress". (combination of git add and git commit) 2) "I want to go back before my previous save." (`git revert` on your last commit) 3) "I want to upload my latest work." (git push) 4) "I want to pull in any new updates." (git pull)
...Et cetera. Stuff that's basic enough to satisfy some basic use cases.
Then, for anything more complicated than this basic subset, users have to whip out the terminal. The balance between basic and complicated, and too little vs too much, might take time to figure out.
Also, stashing could be automatic and rebase could also rebase descendant branches.
Why??
This sounds like something that could break tons of workflows
In fact I've probably experienced more cock ups with git due to its increased complexity and insane naming scheme. I mean "checkout"... Completely inappropriate for what it does.
Obviously with git you can work offline then sync later on, but that's not something you have to deal with in most organisations.
The worst aspect of it though is you can’t set it up to be properly centralized so that you truly bless a location which can keep things like branch name policies, distribute hooks to all employees etc. All that has to be built (poorly) on top, with ample opportunity to accidentally sidestep.
git is that it’s a tool written to solve distributed version control for Linux which is nearly the only project that’s effectively using distributed version control.
Everyone else uses git for centralized version control. And it’a not a perfect fit.
I also used to like when I did not understand git well. After years of learning I mostly understand git and have mostly forgotten that Mercurial exists.
Meanwhile after years of learning I mostly understand git (and am pretty much the reference for colleagues) and I still wish more or less daily its UI wasn't so absolutely shit.
Also revsets, good god of all the awful things in git's UI gitrevisions(7) ranks so, so high.
git is as simple as possible while being as powerful as possible.
What we need is better education! Not only how git works, but also how clean and scaling development workflows work. I've seen too much "Lets just copy the code to the production environment"-workflows in my live already and I do not even have 3 full years of professional experience as a SW dev!
This is far from being a foregone conclusion and would need a careful analysis to justify. FWIW Fossil manages to make do without Git's (insanely named) 'index' (what everyone calls the 'staging area').
Edit: to answer your question, there’s a lot of value to learning the standard industry scm tool.
Maybe I am just dumb .
The first command sets your current comment to parent, with any changes staged, the second commits it.
I don’t mess with the interactive rebase. There’s a magic combination of this and the reflog that can preserve commit history, too.
I read about it in one of Adrian Colyer's "the morning paper" blog posts from 2016, "What’s wrong with Git? A conceptual design analysis" [1], which summarizes the paper that critiques git and describes gitless. (The link to the paper at the beginning of the post no longer works, but a commenter suggested this [2] instead.)
I should point out that I've never used gitless, and I don't know whether it's still maintained, but if nothing else the critique itself is interesting.
[1] https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c...
[2] https://web.archive.org/web/20131230194321/http://people.csa...
Subjectively I think that - the staging area is unnecessarily confusing (mercurial did this better imo), and the overloading of 'checkout' causes confusion too.
Anything about undoing commits, going back to a specific version of the code is less painful but I almost always have to google for it because that are not daily operations and I can't reliably remember them. Maybe that would be easier if I used a GUI instead of the command line. Anyway, a simplified git with only basic functionality and dead simple error messages AND part of the standard git distribution would be very useful. After all git does a lot of things but I'm using only a core 1% of it. Even after 10+ years I reliably know only the basic clone, add, pull, push, checkout, branch, commit, merge, rebase, log, diff commands. I have to google everything else, even how to track a remote branch. It's checkout -b but Gould I also fetch and pull it before? You got the idea.
And it should be about files, directories and branches, the stuff developers reason about.
Git might not have the best interface, and you could argue for different models, but some of this stuff just takes time and effort to learn. This is an important lesson for new developers to learn: some of this stuff is not, in fact, easy, and I don't where this expectation that it is comes from. It reflects a disturbing trend of learned helplessness I've noticed from newer developers. Computers are hard, but if you want to be the expert, you're going to have to figure it out. I don't think we need easier version control, I think we need developers who are willing to learn hard things.
For a different model (and other types of workflows), consider Fossil SCM. [3] Here’s a comparison of fossil with git, and what these tools are a good fit for. [4] I found fossil easier to understand, relatively speaking, and it seems simpler for personal use and for small teams.
[1]: https://gitless.com/
[2]: https://news.ycombinator.com/item?id=29757043
[4]: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...
It's not that git is special or especially hard. It's that distributed source control is a hard thing to understand, and no 20 minutes tutorial is going to solve that.
Git tower is a “simpler git” that makes many complex tasks safer and easier. But it’s on top of git so you have the full power of git if you do have to jump into the commandline.
But I remember that Pre-git this was hard too - the lack of features in VCS systems made it rather error prone. I recall manual 3-way merges and long conversations with colleagues about the right way to work through an SVN merge. Not to mention automated testing was less widespread, so it was harder to catch bugs.
Git offers more features here. But the truth is the problem is just hard. Combining changes from multiple authors requires knowing both your tooling and code well.
It was initially hard.
But once I read through the excellent Git Book[1] things became very clear and intuitive.
What's needed is better documentation, nothing more.
Let me take a wild guess here, bud, you are definitely an american, amiright?
Git is shit, it just happens to be better than the competition coupled with the fact of its huge market share.
People take that to mean they need to learn and teach git in intricate detail, and use it in ways that are needlessly complex, which is dumb.
