How to make git-log scroll up instead of down

Question

Whenever I view a git log --all --graph --oneline --decorate output in my terminal emulator, the first commit is viewed at the top of the terminal screen. When I quit the git log output view with q, a few lines from the are not visible any more, as there are some new lines appended to the bottom of the screen, for the next command.

Usually though, those top lines are the most interesting, as they resemble the most recent git history, so I want them to be still visible when I type the next git command.

How can I make the git log output appear starting at the bottom of the screen, i.e. such that the first commit is viewed at the bottom? You would have to scroll up to view older commits.

NOTE: The --reverse flag is not an option for two reasons.

1. Each time you have to scroll all the way to the bottom to view the first commits. That should not be necessary. I want to start at the bottom.
2. It doesn't combine with the --graph flag: fatal: cannot combine --reverse with --graph.

Answer 1

Original answer, which doesn't work, so goto EDIT for the working version

The following sed solution works for me if used directly form command line. It does not use any temporary string to switch \ and / by relying on seds y command.

$ git --no-pager log --all --graph --decorate --oneline --color=always | tac | sed 'h
s!\( *[0-9a-z]\{7\} .*\)\{0,1\}$!\1!
y/\\\/_¯/\/\\¯_/
x
s!\(.*\)\( *[0-9a-z]\{7\} .*\)\{0,1\}$!\2!
x
G
s/\n//' | less -X +G -r

It assumes the SHA code to be 7 characters long and uses it to "recognize" what is not the leading sequence of \, /, |, _, *, and <space>, which I was not able to put at the beginning of the first s command's search pattern and in place of the first . in the second s command.

I don't know why I cannot get it to work when all sed commands are put in a script called in with seds -f option.

EDIT (The above code is actually faulty)

As @user1902689 pointed out, sed scripts can make anyone's eyes bleed, myself included, since they are extremely cryptic.

In my opinion, the task would be easily accomplished if the --color=always was not used, in which case the text piped out of git log would be the same as we see on screen; using --color=always, on the contrary, inserts control sequences like ^[[33m interspersed in the text to control the coloring (different colors for different branches, ...).

But having a colored output is nice, so I directed the output of git log --color=always ... to file, and looked into it, discovering that the hash always appears in between ^[[33m and ^[[m, where ^[ is a single character obtainable by hitting Ctrl+V, then Esc. These are essentially the escape sequences interpreted by bash as setting the color to yellow, and back to white, respectively (link).

The hash, which is not the only 7-alphanumeric characters-string in the line (e.g. thiswrd can be in the commit main message), is almost certainly the first one, so greedy expressions (sed has no non-greedy expressions) can be safely used after it, and not before (a .* before the hash-matching regexp would make that regexp match the last 7-alphanumeric characters-string on the line, which could be anytext, for instance, and the hash would be lost somewhere in .*). In order to allow the use of the greedy .* in a way that it doesn't devour the hash, we can enclose the hash in between newlines \n which are not matched by the . in .* (and, as such, they must be explicitly typed) with an s command, so that we can "limit" the greediness of .* in a successive s command by using some \n explicitly in the search pattern.

I think the following code (explained afterward) is not definitive, since it hardcodes the coloring escape sequences used to get a colored hash string, but it works as long as I've tried.

$ git --no-pager log --all --graph --decorate --oneline --color=always | tac | sed '
s/\(\(^[\[33m\)\([0-9a-z]\{7\}\)\(^[\[m\)\(.*\)\)/\2\n\3\n\4\5/
h
s/^.*\(\n[a-z0-9]\{7\}\n.*\|$\)/\1/
x
s/\n[a-z0-9]\{7\}\n.*$//
y/\\\/_¯/\/\\¯_/
G
s/\n\([a-z0-9]\{7\}\)\n/\1/
s/\n//' | less -X +G -r

Each line contains the three parts Graph OpeningColorTagHashClosingColorTag Message, or only the first one, Graph. The sed string consists of 9 commands that do what I intended to do with the original answer, but in a bit different way (especially in that the order of some commands is inverted, to save a x command).

1. The first s command puts a newline \n on each side of the Hash string [0-9a-z]\{7\} (or does nothing if there is no hash in this line; note that the lines before/after a merge/diverge have no hash or message following them). This has the purpose of "isolating" Hash. Note that the capturing groups \(...\) are numbered based on the order of occurrence of the opening token \(, so in the replacement string \2\n\3\n\4\5:^†
   • \2 refers to ^[\[33m, which is the OpeningColorTag (NOTE: ^[ is a single character obtained by hitting Ctrl+V, then Esc, whereas the "true" [ must be escped with a backslash \);
   • \3 refers to Hash, [0-9a-z]\{7\}
   • \4 refers to the ClosingColorTag, ^[\[m (what is said for \2 holds here too);
   • \5 is whatever follows, .* (implicitly up to end-of-line).

Now the pattern space (the current line, as we've edited so far) contains the original line with two embedded newlines on each side of the hash (Graph OpeningColorTag\nHash\nClosingColorTag Message), or the unmodified original line if it contained no hash (Graph).

2. The h command "saves" the pattern space into the hold space (think of it as a drawer).

Now the pattern and hold spaces have the same content (Graph OpeningColorTag\nHash\nClosingColorTag Message or Graph).

3. The second s command captures and replace, with itself only (/\1/) and discarding everything before it (^.*, i.e. Graph OpeningColorTag), either (\| separates alternatives in a capturing group \(...\))
   • the newline-enclosed hash and everything following it (i.e. the commit main message) \n[a-z0-9]\{7\}\n.*,
   • or the end-of-line $,

Now the pattern space contains \nHash\nClosingColorTag Message, or the empty string if there was no hash.

4. The x command exchanges the contents of pattern and hold spaces, so that the multiline \nHash\nClosingColorTag Message (or the empty string) is saved in the hold space, and the multiline Graph OpeningColorTag\nHash\nClosingColorTag Message is in the pattern space, ready to be re-edited.
5. The third s command command strips off the \nHash, and everything following it, from the pattern space.

Now the pattern space contains Graph OpeningColorTag.

6. The y substitutes each character between the first two non-escaped /, with the corresponing character between the second and third non-escaped /. Here both back and forward slashes must be escaped with a backslash. (This shoul be safe, since OpeningColorTag should not contain any of the translated characters.)

Now the pattern space contains Hparg OpeningColorTag, where Hparg is the "inverted" version of Graph (or Hparg only).

7. The G command gets the content of the hold space and appends it to (hence the capital G; the lower case g would copy into instead of append to) the pattern space, with a newline \n in between.

Now the pattern space contains Hparg OpeningColorTag\n\nHash\nClosingColorTag Message (or Hparg\n only), and we don't care the hold space from now on.

8. The fourth s command captures the \nHash\n part and substitutes it with Hash.

Now the pattern space contains Hparg OpeningColorTag\nHashClosingColorTag Message or Hparg\n.

9. The last s command removes the remaining newline \n.

Finally the pattern space contains Hparg OpeningColorTagHashClosingColorTag Message or Hparg.

Steps 8. and 9. cannot be fused together (e.g. s/\n\n\([a-z0-9]\{7\}\)\n/\1/), since the two \n enclosing the hash are there only if the line contains the hash (the first s of point 1. does nothing if there's no hash), whereas the first \n is always present, since it comes with the G command.

---

^{† Actually the most external group \(...\) is not needed (it's not used, indeed), so it can be removed, and all numeric references to the other capturing groups can be diminished by 1, e.g. s/\(\(^[\[33m\)\([0-9a-z]\{7\}\)\(^[\[m\)\(.*\)\)/\2\n\3\n\4\5/ can be changed to s/\(^[\[33m\)\([0-9a-z]\{7\}\)\(^[\[m\)\(.*\)/\1\n\2\n\3\4/; but I'll keep the unnecessary group in the answer, since it gives the chance to mention the not-so-widely-known numbering of capturing groups.}

Answer 2

A command that comes close to the intended result is

git --no-pager log --all --graph --decorate --oneline --color=always | tac | less -r +G -X

However, this still messes up the graph a little bit, as the slashes are not reversed properly.

Update

This command takes also care of swapping the slashes with backslashes and vice versa.

git --no-pager log --all --graph --decorate --oneline --color=always | tac | sed -e 's/[\]/aaaaaaaaaa/g' -e 's/[/]/\\/g' -e 's/aaaaaaaaaa/\//g' | less -r +G -X

The corresponding git alias is

[alias]
    rlog = !"git --no-pager log --all --graph --decorate --oneline --color=always | tac | sed -e 's/[\\]/aaaaaaaaaa/g' -e 's/[/]/\\\\\\\\/g' -e 's/aaaaaaaaaa/\\\\//g' | less -r +G -X"

Answer 3

First of all you can alway pass -n to the log to print out any number of commits you are interested in.

---

How can I make the git log output appear reversed

Use the --reverse flag:

--reverse

Output the commits in reverse order.

git log --reverse

You can read here for more tips and flags regarding git log:
http://www.alexkras.com/19-git-tips-for-everyday-use/