Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

On 'porcelain', the way Git uses that term is a pet peeve of mine. On the one hand, the intended meaning of it is that "porcelain" commands are meant for humans, not for other programs - scripts should use the "plumbing" commands (apparently, it's a toilet analogy). On the other hand, the flag that makes "porcelain" commands write machine-readable output is called... "--porcelain". Implying it does the opposite of what it does.

View on HN

It makes more sense if you look at the whole option.

  ... --porcelain[=<version>]

The idea is to present the porcelain at a specific version. So really you should read it as "give me the porcelain (for v1)", e.g.:

  git status --porcelain=v1

If it was an environment variable instead it would be

  GIT_PORCELAIN_VERSION

But that's not what it does. Try it.

    $ git status
    On branch master

    No commits yet

    Untracked files:
      (use "git add <file>..." to include in what will be committed)
     foo

    nothing added to commit but untracked files present (use "git add" to track)
    $ git status --porcelain=v1
    ?? foo
    $ git status --porcelain=v2
    ? foo
    $ git status --porcelain=v3
    fatal: unsupported porcelain version 'v3'

No --porcelain option gives you the output in the format of the git status porcelain, either at the current version or at Git 1.x or whatever, i.e., "give me the porcelain" is the wrong reading of the option.

The correct reading is "I am implementing a porcelain myself, give me a format I can parse in order to do that."

It’s funny how wrong this is.[1] No, `--porcelain` is machine output format, and the machine output format is (sensibly) versioned (you of course need to version such output—the output of `git status` writ large is not versioned afaik).

This [2] answer by VonC even quotes a mail where someone said that it was “[their] fault, to some degree.”

[1] Because it proves the opposite point.

[2] https://stackoverflow.com/questions/6976473/what-does-the-te...

Gah, I'm beginning to think the git CLI is trying to be confusing on purpose.

https://stevelosh.com/blog/2013/04/git-koans/

Is the zen of git to stop using git? Somewhat inspired by OpenBSD I spun up my most recent side project with cvs. I'm amazed how much less stressful code management has become. Makes me want to go further back in time and learn how to properly use rcs.

I think the author of that blog post prefers Mercurial.

Now try a merge.

I've done a few, it's been fine. If you try and use cvs like git sure you're going to get burned. There's a reason Linux was using Bitkeeper and not cvs after all. But if your project organization works well with cvs, you can seriously avoid the massive wad of incidental complexity that is git.

I mean, when I was using cvs because cvs was the only thing I could use I don't think I was trying to use it like git and I was still pretty happy when better things came along. Subversion and perforce in particular improved merging massively long before git came onto the scene.

CVS was fine for small projects with a couple devs at most. Anything more than that and you needed someone on your project with far more domain knowledge in cvs than git requires now to avoid losing all your data in a botched operation on the thousands of independent rcs files a repo consisted of, so I really can't agree about avoiding massive wads of incidental complexity.

Git is, if anything, far simpler than cvs in just about every way imo. I could see myself using subversion for a lark, but I'm very happy if I never have to touch cvs again.

> The novice thought for a few moments, then asked: "Surely some of these could be made more consistent, so as to be easier to remember in the heat of coding?"

> Master Git snapped his fingers. A hobgoblin entered the room and ate the novice alive. In the afterlife, the novice was enlightened

> ... scripts should use the "plumbing" commands (apparently, it's a toilet analogy) ...

Ah this term finally makes sense to me, since it's meant to deal with human output.

Wasn't machine readable output is obtained via --terse historically? Some toolkits we use provide --terse flag to dump output in a pipe friendly manner.

Reply on news.ycombinator.com