[karmakaze]

Git shouldn't take months to master if you can understand it conceptually rather than by use-cases. If instead of trying to learn commands to affect the working directory, staged files, or history, you learn how git organizes historical tree of commit hashes, then base what each operation does, it becomes much clearer. It's similar to trying to learn strings of shell pipe commands to get things done rather than realizing that there's pieces of work that each command can do. One tip is to use (even very temporary) branches rather than `stash`es unless it's absolutely short lived. And if you ever get lost, `reflog` is your friend.

For me, I had trouble first using `git` after experience with `cvs` and `subversion`. At some point, everything clicked because I inferred its internal model.

[DaiPlusPlus]

git’s problem to newcomers - even people without any prior experience with diff-paradigm systems like SVN and TFS - is the idea of a commit representing a snapshot of a file system is difficult to comprehend because it feels so crazy and impractical (especially as CS101 makes a huge deal about computational complexity). The fact that git internally is actually quite efficient is buried in heavy articles about git’s plumbing.

Oh, and the fact that a ‘git checkout’ is an unrelated concept to ‘svn checkout’ - and how SVN branches are “spatial” compared to git’s “parallel-universes” model is also a source of confusion.

If I could go back in time to 2005 (in addition to getting in super early on bitcoin) I’d beg Linus to not reuse SVN terminology. Personally I’d go with “git switch” instead of checkout, and “timeline” or “line” for short instead of “branch”. The fact that git branches are not 1-connected graph routes is enough reason not to call them “branches”.

I’d also convince him to include a “gitd” mode that would automatically fetch from upstream and automatically add commits when it detects file-move/rename changes. (I understand why git doesn’t have an exact “rename” op, but tooling today still isn’t good enough to detect rename-then-edit or rename-then-split operations without an intermediate rename-only commit. My dream “gitd” would also make auto-commits every 30 seconds just to give me a powerful filesystem undo feature. If you had hours of work that resulted in new files before you staged them and you accidentally did a hard reset then you’re sol - and this has happened to me already :/

[webreac]

IMHO, the main idea of git is immutability. See the following comparison of git and synergy in a migration study. https://github.com/24eme/eurocontrol_synergy2git/blob/master... The git description is far shorter, but also more complete.

[DaiPlusPlus]

In practice, git isn't immutable - people rebase their commits after pushing, or go back in time to remove a file that shouldn't have been there and reindex, and so on.

[webreac]

These actions are not modification, but creation of an alternate reality (commit tree). This gives trust that if we are not happy with this alternate reality, we have some time to revert to the original one (untill garbage collector remove it).

[karmakaze]

It makes complete sense for programmers learning git to also learn some relevant underpinnings of what git is doing (not necessarily how it achieves it so efficiently). That is a much quicker route than having users guess at similarities with things they've used or imagine while using it and being surprised with it veers off expectations.

[thinkingemote]

When I used to use NetBeans the main feature I loved was the history feature.

Basically every save to every file was stored and diffable in a kind of self contained repo.

I've missed this feature in every other editor since.

[qw]

IntelliJ IDEA has that feature (local history)

[james_s_tayler]

Can confirm.

[jki275]

NetBeans is a wonderful IDE for this reason.