glab api

glab is GitLab’s command-line client, a Go program GitLab’s engineers own and maintain, and the client a model drives when it works a GitLab project from a terminal, as in gitlab-contribution. Its api subcommand is the raw request: a call to any REST or GraphQL endpoint with the token glab already holds, --field and --raw-field turning key=value pairs into parameters. The changes in the rail are mine, inside the maintainers’ command; each closes a gap between how a request reads and what goes out on the wire.

• A --field value opening with [ or { decodes as JSON, numbers at full precision, trailing text an error; --raw-field sends the same text as a string.
• Names are never parsed. On GET and DELETE the fields become a query string, where ids[] and position[base_sha] arrive percent-encoded as the parameters they spell.
• Both flags collect into one ordered list, so -f 'ids[]=1' -f 'ids[]=2' sends both values in the order typed. -F 'ids=[1,2]' emits the same repeats, so spelling one parameter both ways is an error: nothing says which order the values belong in.
• On every other method, unless --input supplies the body, the fields are a JSON body, and a bracketed name is an error: it would go out as one literal key the API ignores, and the request would succeed without doing what was asked.
• --paginate follows the Link header’s rel="next" URL as given. It already carries the first request’s parameters, so on a query method the fields are dropped after page one; rebuilding them would double array values and let a caller’s page=1 override the server’s page. Other methods keep sending their body.

Outside api, mr create --draft and mr update --draft share one helper that knows every marker GitLab reads as a draft, Draft:, [Draft] and (Draft) in any case, so a marked title is not prefixed again.

The rules in full are glab’s own api reference, generated from the command’s help.

---