For git log, the --abbrev=<length> parameter controls how long the output for %h and other abbreviated hashes is:
$ git log -1 --format=%h --abbrev=4
d157
I will also note that when using -1 (or --no-walk which has the same effect in this particular case, but is more useful if you specify several commit identifiers), if all you want is the commit hash, using git log is overkill: git rev-parse will get you the hash. For no obvious reason, the control knob for limiting git rev-parse's commit IDs to a particular length is spelled --short rather than --abbrev; and git rev-parse requires that you spell out HEAD if you mean HEAD, so:
$ git rev-parse --short=4 HEAD
d157
How long or short can you go?
The longest is pretty long, currently 40 characters, probably 64 in the future. The shortest you can ever go is four characters, which works in tiny repositories. But the shortest you can go in some particular repository may be more than four characters.
For output, you can ask for the --short or --abbrev length to be any value you want. Values that are too small or too big will be raised or lowered as needed. (Note that in truly ancient versions of Git, it might show you four character hashes if you ask for them, even if they're too short to be unambiguous. Current Git is smarter.)
When you supply a shortened raw hash ID of at least four characters yourself, though, if it's too short, you'll get an error like this one:
$ git rev-parse 1111
error: short SHA1 1111 is ambiguous
hint: The candidates are:
hint: 111116ea13 blob
hint: 1111f64dd9 blob
1111
fatal: ambiguous argument '1111': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Older versions of Git aren't as nice about their error messages; this one, which—if you read the hint: output lines—tells you that you need at least 11111 or 1111f to pick one of the possible results, is from Git 2.27.0.
Since Git repositories grow over time, it's possible to use a very short hash ID early in the repository's lifetime, and later—say, in five years—discover that this short hash ID is now ambiguous. The Linux kernel, for instance, is now up to the point where git log --oneline uses 12 characters for safety. If you set a very short --abbrev, the git log output will have varying output hash sizes since each one gets extended to the necessary minimum:
$ git log --oneline -n 12 --abbrev=4
0f1a7b (HEAD -> master) timer-of: don't use conditional expression with mixed 'void' types
5021b9 Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
714366 Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
65aa35 Merge tag 'erofs-for-5.4-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs
3fd57e7 char/random: Add a newline at the end of the file
Note how commit 0f1a7b3fac0583083ca19d4de47403511ced3521 was able to be shortened to 0f1a7b (six characters), but commit 3fd57e7a9e66b9a8bcbf0560ff09e84d0b8de1bd took seven (3fd57e7). There are currently two objects with 3fd57e as their first six hexadecimal digits of their hash IDs: one commit object and one tree object. Over time, as more objects accumulate in the Linux kernel repository, even 3fd57e7 may become ambiguous.
