> I don't think it's as appreciated that git's complexity generally discourages people from trying things out.
For me, at least, the underlying model actually makes it easier to try things out. As long as my work is in commits and I have refs that point to those commits, I can be pretty sure that I'm not going to lose anything. I also take a fair amount of comfort in the fact that (unlike, say, SVN), any remote actions can be deferred until I know things are correct locally.
This sort of robustness in the data model makes it a bunch easier for me to forgive the (very real) usability issues in the command line UI. (And, after years of work, the command line is getting more familiar, aside from some of the more complex rebase operations.)
> I don't think it's as appreciated that git's complexity generally discourages people from trying things out.
Personally, I'm not shy about recursively copying the entire repository on disk to run potentially destructive experiments in a duplicated environment.
Also, once you understand how to pull things out of the reflog, it's usually not hard to restore to a sane state.
> I'm not shy about recursively copying the entire repository on disk
Agreed.
> Also, once you understand how to pull things out of the reflog,
That, and I'll also dump a git log of the last couple dozen commits into an editor buffer so that I can hang onto the commit ids. Until a GC cycle occurs, you don't lose the commits even if they aren't reachable through normal paths.
`git reflog` gives you the historical list of SHAs that you've pointed HEAD at; even if you destroy your branch with a rebase, you can still see what commit your branch pointed to before you started the operation.
Yeah... I just find the printed log output a bit easier to read (at least for the few times I need to do this sort of thing). '@' syntax falls into that same basic category - powerful, the better solution, but nothing I use enough to bother mastering.
I want a VCS that does NOT try to hide how it works from me.
I love that git gives me a) a bag of commits forming one or more rooted trees, b) symbolic names for commits/branches that resolve to individual commits in that bag.
That's such a simple model.
Remotes. Commits. Branches/tags. That's it.
Merging and rebasing merely create new anonymous branches in the bag of commits, then move a branch name (if applicable) to point to the new HEAD. Done. Trivial.
The reflog is just a local log of actions taken, and can be used to quickly recover from missteps: just find a HEAD you want as your branch's head, and then git branch -f branch <commit>.
The index/staging area are very, very useful, mostly because of git add -e, which is extremely powerful. This lets me split up my commits usefully.
Just about everything else is stuff you can figure out as you go.
The only thing you can ever lose in git (short of doing rm -rf .git) is workspace content that you have not added to the index or committed. Stay away from git reset unless you know what you're doing with it, and all is good.
Being able to think of the state of the repo as a tree of anonymous commits, with a name resolution table for resolving branches/tags to commits, makes doing complex tasks trivial for me. I often rebase in detached head mode and nothing goes wrong; when I'm done I manually move/create a branch to the new HEAD -- I can do this because the tree-of-anon-commits model is so darned simple.
Now, can that be explained to a git newbie in under half an hour, to get them up and running?
IMO, the scary UI/UX of git is holding back the use of version control for a lot of digital documents beyond just source code. It needn't be this complicated.
I've tried to get noobies to use SourceTree on OS/X, with Mercurial or git, and it never goes well. Version control is just hard the moment you want to do anything other than linear commits. The moment you want to undo something partially, it gets ETOOHARD on most non-developers, and especially people like my mom.
On the other hand, when explaining the git model to sysadmins and developers, not sugar-coating it has worked best for me. I explain the bag-of-commits+nametable design. I explain the workspace and staging area. I show how one does things. This works for me.
Maybe git's UI "needn't be this complicated", but I do find that Mercurial's heavy-duty branches lead to hell very quickly and it's always difficult to recover -- and Mercurial is supposed to be simple! The lesson is that simplifying isn't easy, and not every simplification works well generally.
With git I can simplify in that I show users a small amount of abstract concepts (bag-of-commits, nametable) and a small set of common usages and then let them learn by experience and osmosis as they reach out for help when they stray past those usages. I can't do this with other VCSes. At some point it just becomes painful.
One of the nice things about git is that I can push users to make very linear history. This is nice because diving into the history of a tangled mess of merged branches is not easy, and it's actually very confusing to non-professionals. But even for professionals, linear history is far superior to a tangled mess of merged branches, and only git really gives us that power today.
For me, at least, the underlying model actually makes it easier to try things out. As long as my work is in commits and I have refs that point to those commits, I can be pretty sure that I'm not going to lose anything. I also take a fair amount of comfort in the fact that (unlike, say, SVN), any remote actions can be deferred until I know things are correct locally.
This sort of robustness in the data model makes it a bunch easier for me to forgive the (very real) usability issues in the command line UI. (And, after years of work, the command line is getting more familiar, aside from some of the more complex rebase operations.)