3 ms·
How is it that git still doesn't have machine readable output built in?
by stephenr 9y ago
How is it that git still doesn't have machine readable output built in?
- Sean1708 9y agoIsn't that what the --porcelain option[0] is for? And for commands that aren't porcelain, what's wrong with --oneline or --format? [0]: https://stackoverflow.com/questions/6976473/what-does-the-term-porcelain-mean-in-git#6978402 https://stackoverflow.com/questions/6976473/what-does-the-te...
- sevensor 9y agoIn what respect is --pretty=format not producing machine-readable output? Is putting null bytes between the fields not machine-readable enough for you? You want to use 0x1d instead? You could do that.
- stephenr 9y agoIn the way that you have to futz around like this with null byte separators to try and avoid escaping issues. Svn had a flag to output resonses in xml specifically for machine consumption. No ambiguity about what it would provide, or if it was escaped or how to handle things like new lines etc.
- IshKebab 9y agoBecause if you want machine readable output you shouldn't be parsing the output of other commands - you should link with libgit2. It's actually very easy.
- sevensor 9y agoI'd quibble with your premise that inserting unambiguous delimiters doesn't make a machine-readable text format, but I'm so happy to have learned about the existence of libgit2 that I won't press the issue. Machine-readable text is great and all, but libgit2.so is even better.
- mbrock 9y agoIt is great indeed, but operationally, dynamic libraries have their own problems and horrors.
- deathanatos 9y agoIt… does? In the specific case of git-log, is not --format=raw machine-parseable? If you only need pieces or parts of the commit, specific format strings can be used, but you can still get those to be machine parseable pretty trivially.