Turn Git Input into Predictable Columns with git column

A list of names dumped one per line is unreadable, and git column is the tool Git uses internally to fix that, one you can call directly too. This guide gets you a repeatable way to format newline-separated input as a table, choose whether values fill down columns or across rows, and make the result fit a known width. The examples use Git 2.43.0, installed here from the git-man package version 1:2.43.0-1ubuntu7.3. Allow about ten minutes. You need Git and a shell; no repository or elevated privilege is required.

1. Confirm the installed command

Run these ordinary, read-only checks:

$ git --version
git version 2.43.0
$ git help column

The second command opens the local manual in your configured pager. You usually invoke it as git column, even though its manual page is named git-column. If git help column comes up empty, check that the Git documentation package is installed. Do not use sudo to format ordinary input.

2. Format one value per input line

Use --mode=column to fill the first column, then the second, working down the table. Set --width in scripts and examples so the output does not depend on the terminal it happens to run in:

$ seq 1 12 | git column --mode=column --width=24 --padding=2
1   3   5   7   9   11
2   4   6   8   10  12

The input here is twelve lines, and the width allows six columns. Nothing is being numerically sorted: Git is preserving the input sequence while placing lines into cells. --padding=2 asks for two spaces between columns, and the visible alignment also depends on the width of the cells themselves.

$ seq 1 12 | wc -l
12

3. Choose row-first layout when reading across is clearer

--mode=row fills the first row before moving to the next, which suits a short list that people scan left to right:

$ seq 1 12 | git column --mode=row --width=24 --padding=2
1   2   3   4   5   6
7   8   9   10  11  12

The width is a maximum layout width, not a request to truncate anything. A single long value can force fewer columns, or make the table wider than the number you supplied. If the output has to fit a fixed interface, keep labels short and test with the longest one you expect.

The third layout, plain, deliberately produces one cell per line. It is a useful escape hatch whenever columns would make copying or comparing values harder:

$ printf '%s\n' alpha beta gamma | git column --mode=plain
alpha
beta
gamma

4. Control the table boundary

Reach for the remaining formatting options only when a consumer needs a specific shape:

• --width=<number> sets the terminal width used for layout. Without it, Git detects the terminal width and falls back to 80 when it cannot.
• --padding=<number> sets the spaces between columns. The default is one.
• --indent=<text> prefixes every output line with the supplied text.
• --nl=<text> replaces the line ending appended to each output line. Include an actual newline in the value if a downstream format needs one.

For example, this adds a prompt-like prefix and a semicolon after every formatted line:

$ printf '%s\n' red green blue | git column --mode=column --width=20 --indent='items: ' --nl=';' --padding=1
items: red  green  blue;

5. Use Git configuration without losing the test

Git's column-aware commands consult column.ui and more specific settings such as column.branch, column.status and column.tag. column.ui actually combines three separate decisions:

Test a configuration for one command with -c instead of touching your global file:

$ printf '%s\n' a b c d | git -c column.ui='always,row' column --command=demo --width=5 --padding=1
a  b
c  d

--command=demo tells git column to look up column.demo and then fall back to column.ui. The one-shot -c setting disappears the moment the command exits. If you later decide on a persistent change with git config --global, treat it as a user-environment change: record the old value first with git config --global --get column.ui, and undo one you added with git config --global --unset column.ui. Do not copy a global setting into automation without deciding whether non-terminal output should stay stable.

6. Diagnose the usual surprises

• Pipeline seems to ignore columns? Check whether it is reading from a terminal. Configuration set to auto is meant to behave differently once output is redirected. For a deterministic pipeline, pass an explicit --mode and --width, or use a one-shot -c setting.
• Values look reordered? Check the mode first. column and row are both order-preserving, they just place the same sequence into different coordinates.
• Values missing? Check the producer and its exit status. Git column does not fetch, filter or repair input on its own.
• Label contains spaces? It is still one input line and therefore one cell. Quote the label when you create it in the shell, but do not expect git column to parse shell quoting from standard input. A label containing a newline is two input cells by definition.

Keep machine-readable output separate from presentation. Tables suit a human terminal; for a script, consume the original newline-separated values unless the receiving interface explicitly wants the formatted layout. Nothing in these examples is destructive, and none of it needs a service restart or a privileged action.