Git commit using stdout from bash

While there is not any utilities that come with git that lets you do what you want, it is rather easy to write a python script that parses a git object and then outputs the author and commit message.

Here is a sample one that expects a git commit object on stdin and then prints the author followed by the commit message:

from parse import parse
import sys, zlib

raw_commit = sys.stdin.buffer.read()

commit = zlib.decompress(raw_commit).decode('utf-8').split('\x00')[1]
(headers, body) = commit.split('\n\n')

for line in headers.splitlines():
    # `{:S}` is a type identifier meaning 'non-whitespace', so that
    # the fields will be captured successfully.
    p = parse('author {name} <{email:S}> {time:S} {tz:S}', line)
    if (p):
        print("Author: {} <{}>\n".format(p['name'], p['email']))
        print(body)
        break

To make a full utility like you want the server needs to support the dumb git transport protocol over HTTP, as you cannot get a single commit using the smart protocol.

GitHub doesn’t support the dumb transport protocol anymore however, so I will be using my self-hosted copy of Linus’ tree as an example.

If the remote server supports the dump http git transport you could just use curl to get the object and then pipe it to the above python script. Let’s say that we want to see the author and commit message of commit c3fe5872eb, then we’d execute the following shell script:

baseurl=http://git.kyriasis.com/kyrias/linux.git/objects
curl "$baseurl"/c3/fe5872eb3f5f9e027d61d8a3f5d092168fdbca | python parse.py

Which will print the following output:

Author: Sanidhya Kashyap <sanidhya.gatech@gmail.com>

bfs: correct return values

In case of failed memory allocation, the return should be ENOMEM instead
of ENOSPC.

...

The full commit SHA of commit c3fe5872eb is c3fe5872eb3f5f9e027d61d8a3f5d092168fdbca, and as you can see in the above shell script the SHA is split after the second character with a slash inbetween. This is because git stores objects namespaced under the first two characters of the SHA, presumably due to legacy filesystem having low limits on the number of files that can reside in a single directory.

While this answer doesn’t give a full working implementation of a remote git-show command, it gives the basic parts needed to make a simple one.

After digging with XFT_DEBUG flag I found something weird. I run the command with the flag and navigate to the problematic commit:

❯ XFT_DEBUG=1 gitk --all
XFT_DEBUG=1
XftFontInfoFill: /usr/share/fonts/truetype/noto/NotoSans-Medium.ttf: 0 (15.9999 pixels)
XftFontInfoFill: /usr/share/fonts/truetype/noto/NotoSans-Medium.ttf: 0 (15.9999 pixels)
…
XftFontInfoFill: /usr/share/fonts/truetype/noto/NotoSans-Medium.ttf: 0 (17.5999 pixels)
XftFontInfoFill: /usr/share/fonts/truetype/noto/NotoSans-Bold.ttf: 0 (17.5999 pixels)
XftFontInfoFill: /usr/share/fonts/truetype/noto/NotoSansSymbols2-Regular.ttf: 0 (17.5999 pixels)
XftFontInfoFill: /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: 2 (17.5999 pixels)
XftFontInfoFill: /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: 0 (17.5999 pixels)
XftFontInfoFill: /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: 0 (109 pixels)
X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  20 (RenderAddGlyphs)
  Serial number of failed request:  6687
  Current serial number in output stream:  6706

Then spotted the last line prior to the fail had an excentric pixel size

XftFontInfoFill: /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: 0 (17.5999 pixels)

XftFontInfoFill: /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: 0 (109 pixels)

Removing the Noto-color-emoji fonts solved the issue

apt remove --purge fonts-noto-color-emoji

No more crash and a consistent font size is used to render

XftFontInfoFill: /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: 2 (17.5999 pixels)

Version

❯ apt show fonts-noto-color-emoji
…
Version: 0~20200408-1