5 ms·

The git man pages is famously inaccessible if you don't already know the concepts and jargon of git. The following auto generated satire is both hilarious and s

• acqq 7y ago
  To compare, a real small part from "man git checkout": "git checkout --detach [<branch>] git checkout [--detach] <commit> Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications. When the <commit> argument is a branch name, the --detach option can be used to detach HEAD at the tip of the branch (git checkout <branch> would check out that branch without detaching HEAD). Omitting <branch> detaches HEAD at the tip of the current branch. git checkout [<tree-ish>] [--] <pathspec>… Overwrite paths in the working tree by replacing with the contents in the index or in the <tree-ish> (most often a commit). When a <tree-ish> is given, the paths that match the <pathspec> are updated both in the index and in the working tree. The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result." Well yes of course.