Git In Two Minutes (updated after 8 years)

Saw this though for switch/restore:

"THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."

Sometimes, they are really stupid, and they will checkin passwords.

With the RCS archives, I can use vi (or nano, or any other reasonable editor), and remove this foolishness.

When I run "git cvsconvert" any foolishness is ENGRAVED IN STONE.

Removal is possible in git, but not easy.

This is my problem. THERE ARE SO MANY IDIOTS. What can I do?

EDIT: For Windows-centric users of git, you need to run this in every and all repositories RIGHT NOW.

git grep -i password $(git rev-list --all)

[actually, everybody should try it]

I find I don't ever bother with managing local branches for anything in my own workflows. I just git-reset --hard to bounce between fetched copies of upstream branches as needed. Stuff I need to work on for more than a few commits in an afternoon gets pushed to a remote branch regularly anyway as part of general safe development hygiene.

It sounds like switch and/or restore are probably stable enough that they could be used instead of checkout for the specific tasks I'm trying to do in the blog post, so yet another update will be warranted when I get a chance!

It's completely usable as-is, so I hope no one is scared off by thinking it should incorporate switch and/or restore. It's usable now, and if you do feel like saving a link to it for future reference, I expect that there will be another way in the future to do a couple of the tasks using the more modern syntax.

* Since it's an introduction maybe consider "--oneline" instead of "--pretty=oneline" for memorability

* Undoing a bad commit - since it mentions a commit message typo, maybe instead redo it with "git commit --amend"

You want meaningful history, not unfiltered history.

The harm is that the history is no longer as useful if it's not curated -- whether that's for tracking down the origin of a bug, or just using it to remember what you did a few weeks ago.

It's easy to see the flaw in "keep everything" by taking the argument to its logical conclusion, which would be recording the history of every keystroke in your editor.

If you have false starts or alternate approaches that you gave up on but think you might still want, by all means save them, just not in "main."

Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost.

Git _is_ confusing; it became the de-facto standard because it was the first free DVCS (and DVCSs solve lots of problems that were common to old non-distributed VCSs), not because its UI is particularly well-designed.

Many professional software devs I work with still really have no idea how git works, they've just memorized the 3 or so commands they absolutely need and maybe how to recover when something out of the ordinary happens.

Git is basically a linked list (if you have one branch) and a graph (if you have more than one branch). Then all you are really working with are pointers to certain nodes in that graph.

In git terminology these nodes are called objects and there are different types of objects such as tree objects and commit objects etc. Objects are compressed with a library called zlib and are stored as files within the .git/objects directory, the file name is the hash of the decompressed object.

But, back to the graph and the pointers to certain nodes. A branch itself is nothing more than a pointer either. You can look at the files in .git/refs/heads to see where they point.

Now, what you do with git checkout is changing the node you currently view in the graph. If you make a commit you create a new node. Merging is nothing more than taking two nodes and creating a new node that is connected to both of them.

The main problem i think is that concepts like branch, tag, commit etc are actually just overcomplicated abstractions of the much simpler graph nodes and pointers and are thus confusing.

Git is designed for collaboration. Git's UI is absolutely unintuitive, especially coming from other version control software. But that's irrelevant. Everyone wants to use it because of the network effect.

In terms of _why_ the UI is unintuitive, I believe it's because it intentionally exposes its internal representation. Unlike its predecessors like subversion, Git has infinite flexibility in terms of the workflow that teams of people can adopt. But the flexibility comes at the cost of learning how to use a distributed graph of commits.

Personally, I never learned git by reading recipes of commands, like the OP. I only really grokked it by understanding how it works internally. This article helped me:

Git for Computer Scientists https://eagain.net/articles/git-for-computer-scientists/

I wish the world had standardized on mercurial instead, but here we are.

Locally, git almost makes sense. I make a change, I commit it to the tree of changes. I can roll it back, or branch it off, or merge branches, or restore from a previous point, and so on.

It's when some kind of external repository gets involved where the model breaks down for me, especially if it's public/open source.

Someone wants to help me fix a bug? Cool! They got my code from GitHub and modified it. Now they want their changes to be merged into my version. They submit a pull request. A what? They want me to pull their code into mine? Why isn't it called a push request, where they request permission to push their changes into my maintained repository?

And so on.

https://unix.stackexchange.com/questions/11376/what-does-dou...

This is not git specific, but a common convention for CLI tools. Try running:

    > touch -- -i foo
    > rm -- -i foo

  rm -- -f

You point is what, that these are needlessly asymmetric? It's true. But they're in my head because I do them every day, and it's not like I'm suffering under the burden of remembering a handful of flags. That's a pretty far cry from "not actually usable", so maybe your hyperbole is a little misplaced?

> git branch --all

Tags are different, since they are actual objects in git, but using ls-remote isn’t tough, and one could create an alias.

As I understand it, they're attempting to make it "actually usable" by adding more consistent (and maybe even "intuitive") options to the syntax. In order to avoid a breaking change, though, they're also leaving the old confusing stuff in. Sure, it's regrettable that it's there in the first place, but understandable that they don't want to break people's scripts from, by now, decades back.

Sure, that makes it a little harder to learn, but it can be done, by just making a conscious decision to ignore those crufty old bits.

> This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options).

This is a common idiom, e.g., to grep a file for a pattern that matches a grep argument,

> grep -- -e file

Edit: fixed dash weirdness.

For instance, "git checkout test.c" will check out the file test.c unless you happen to have a branch called "test.c". (See also people complaining that checkout is overloaded".

Simmilarly, "git add --verbose test.c" will add test.c, and log that to stdout. "git add -- --verbose test.c" will add test.c and --verbose, where "--verbose" is the name of a file.

This isn't git specific, most CLI tools use "--" to restrict the parsing on arguements that follow.

That would be nice. It is a pity most man pages are elitist and lack good useful examples.

Because it's about using git as a single-user, single-machine version control tool.

You don't learn anything in two minutes if you don't even read the headline:

> Git In Two Minutes (For A Solo Developer)