gitk | gitk graphical git repository viewer | Command Line Interface library

gitk * (with the star quoted from the shell) causes gitk to run:

The problem is this line, which you say you're doing "just for readability":

What to do?

Just define a function that does the compiletion with leading _git_ prefix.

Git told you:

Type git revert (unwanted commit hash) You can get the unwanted commit hash by using git log —oneline , to get the commit hash e.g cdb76bf

Run git reflog to get Git to spill out the contents of the HEAD reflog. This will get you commit hash IDs (on the left), numbered @{...} suffixed names (next to the hash IDs), and information about what made that the commit that HEAD identified (for commits, that's commit subject lines).

If one of the subject lines looks promising, try that commit hash ID: e.g., git show hash. If that's the commit you're looking for, you've found it: make a branch name for it. If not, keep going with the reflogs. To make a new branch name newname that points to a given commit hash hash, use git branch newname hash.

Given that you have some data you can search for (or a blob hash ID like 9dc18eb8bba4d381ad0a96c782fec57928dc92d2—see the output of git show 9dc18eb8bba4d381ad0a96c782fec57928dc92d2 to see if that's a file of interest, for instance) you can also search the commits in the reflog to see if any of them have, in their snapshots, a file with that blob hash ID. That's usually less effective than the quick "look at the top few reflog entries" method, but note that git ls-tree -r hash | grep 9dc18eb8bba4d381ad0a96c782fec57928dc92d2 is a way to find out whether the given commit hash ID hash refers to that version of the file.

Side note: the answer you linked referred to someone who was in the middle of a git rebase when they did stuff on their detached-HEAD setup, and then lost it; the commands you quoted are useful after you've set up a branch name to be able to find the commits.

This worked for me after I did brew upgrade git-gui

As per comments, it turns out commit 5643f6a7c is in fact a merge commit. The git show command has special handling for merge commits and winds up showing no diff for this file.

The reason git show winds up showing nothing is a little bit complicated in full detail, but has to do with the following:

• Each commit contains a full snapshot: a copy of every file as of the form it had at the time you (or whoever) made that commit.
• Each commit also contains information about the commit itself. We call this the commit's metadata, to distinguish it from the main data (the snapshot). This includes the name and email address of the person who made commit, for instance. It also includes the raw hash ID of the commit's parent commits.

It's the parent linkage, from a commit to its predecessor commit or commits, that allows Git to show you a diff. Most commits have just the one parent. Given that commit C follows earlier commit B, and both commits have snapshots, Git can simply extract—to a temporary area (in memory or whatever)—both snapshots and then compare them. For each file that is the same, Git says nothing. For each file that is different, Git prints the name of the file and a recipe. Apply the change-recipe and this will transform the copy of the file as it appears in commit B to make it match the copy of the file as it appears in commit C.

This recipe, for changing parent commit B into child commit C, is one form of a diff. This diff is what git show shows, after printing a selected (and formatted) part of the metadata from commit C. The git show command can do this because there is only one earlier commit: commit B precedes commit C so whatever changed between B and C is what is of interest. Adding one or more path-names to a git show command limits the diff to just what changed in the selected file(s).

This whole idea fails when applied to a merge commit. A merge commit is a commit with two or more parent commits. Other than having the two or more parents, a merge commit is like any other commit: it has a snapshot and metadata.

In general, we get merge commits by running git merge. (There are other ways to make merge commits and git merge does not always make merge commits, so there's no guaranteed one-to-one correspondence here, but that's the usual way to make a merge. Note, by the way, that the noun form, a merge, refers to a merge commit, probably made by git merge; the verb form, to merge, is the process that git merge uses to come up with the content for the snapshot.

The merge process actually involves at least three commits. We can see how a typical merge comes about by drawing the setup we get if we have two divergent branches:

Solved it by running brew install tcl