Also to learn that `git reflog` exists, and gives you pointers to all the old states of your repo, even mid-merge or mid-rebase. If you get stuck with a bad rebase, you’re only a `git reflog; git checkout HEAD@{3}` away from being back where you started.
Tutorials like this one and others mentioned throughout the thread do a good job of breaking down the viscera from there.
That's not git, that's the command line - the interface with no inline visualization, no discoverability and no affordances.
git is not its command line interface. I use the git CLI like I use curl: a powerful tool for occasional surgical or automated operations directly on underlying protocol. Most of the time I prefer something that better fits my workflow: for git, it's Git Extensions; for HTTP, it's Chrome.
1) uncommitted stuff in workdir. Potentially can be lost, so commit often.
2) blobs in repo representing snapshots at commit time. Can never be lost.
3) symbolic references to the blobs. Can always recover from reflog.
4) tools to sync the above two things between repositories. (fetch and push)
5) tools to merge, diff and otherwise manipulate the changes between snapshots and files.
I'm confident that git will never lose my data, so long as I commit it. This makes experimentation stress-free.
Technically, you can lose data by explicitly deleting your refs, expiring the reflog, and running gc, but if you go that far you might as well rm -r .git
0) you forgot to explain git's index. Mercurial doesn't have the index, it works how you described git.
2) data (blobs, revsets, whatever) in the repo actually can never be lost, there is no automatic gc
3) no need for some different tool/viewer to view commits that don't have refs
Technically there are several ways to remove data from the repo, but it never ever happens automatically behind your back.
I think I've asked this before, but what exactly are mercurial's branches?
In git, they are a "physical" feature of the repository as it represents a set of lineages, not an actual repository object.
As such, any reference to a commit uniquely identifies a branch, so the concept of a "named line of development" is simply implemented as a reference that gets updated as you make more commits. When you "delete" a branch in git, it goes nowhere. Only its name is removed.
What sort of structure does mercurial use to represent its branches? I know they are not just an emergent thing like in git.
Two articles that might help if you really want to dig into it:
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
https://bryan-murdock.blogspot.com/2013/06/git-branches-are-...
The first article also states that unnamed branches are useful for small, temporary diversions, and notes that git has to name branches, but I think that's somewhat misrepresenting git since you can throw away names as soon as they are no longer useful. To me it seems kind of silly to have unnamed branches, given that names are free and much easier to remember than commit hashes.
I think Linus' design goal was something that runs as quickly/efficiently as possible on large repositories.
> it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down
My feeling too!
Git actually doesn’t scale to really huge monorepos.
IMHO the only real advantages over SVN for most users are the better branch/merge functions.
Which is a largish piece of software.
Have you tried looking into any other contemporary DVC systems?
I get Git, more or less. Having tried to make sense of Bazaar or Mercurial on several occasions (to understand the internal data model), I eventually gave up.