I recommend to look into git log --help and git rev-list --help .

I just created 2 scripts to list commits from Git repositories. It’s more in the score of an alias actually, so nothing comprehensive here. If you have some one-liners, alias or scripts for commits listing, please share here. The link of this post goes to the git log documentation. I’ll share mine in the comments too rather than in the post.

  • duckduckduck@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    8 days ago

    The man page sheds a bit of light, but basically it the stuff on top of the core git functionality.

    LOW-LEVEL COMMANDS (PLUMBING)
           Although Git includes its own porcelain layer, its low-level commands are sufficient to support development of alternative
           porcelains. Developers of such porcelains might start by reading about git-update-index(1) and git-read-tree(1).
    
           The interface (input, output, set of options and the semantics) to these low-level commands are meant to be a lot more stable
           than Porcelain level commands, because these commands are primarily for scripted use. The interface to Porcelain commands on the
           other hand are subject to change in order to improve the end user experience.
    

    Related, but not to be confused with the --porcelain option available for some git commands. Eg, from the man page for git status:

           --porcelain[=<version>]
               Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable across
               Git versions and regardless of user configuration. See below for details.
    

    Like it says, if you’re doing any kind of scripting this will remove weird escape codes to make parsing the output easier.

      • bignose@programming.dev
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        5 days ago

        It’s a long-established term in design of software that is intended for use without awkward interaction with the complex internals (the plumbing); we acknowledge that a decent user interface that presents strong, coherent abstractions designed for typical use (a porcelain) is needed.

        The reason it gets so much discussion in the context of Git is because Git desperately needs a good porcelain, and its initial developers agreed one was needed but were profoundly uninterested in writing one; they said other people should do that. And then went on to heavily promote its use, before any decent porcelain existed, so that the plumbing de facto became what people had to use directly.

        So, with Git particularly, no matter what porcelains get created, people are pretty much stuck with learning all the plumbing. It could have been better.

        • Alavi@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          5 days ago

          Thank you for your great explanation.

          Is porcelain inherently different from API? Or are they basically different names?

          • duckduckduck@programming.dev
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            19 hours ago

            Personally, I think that’s a decent mental shortcut. I would call an API “good plumbing.” It kind of depends on your audience, for some the API is for the intended audience (developers), but from their perspective the API may be the plumbing while they provide a higher level tool (eg. a GUI) for their intended audience (regular people).

          • bignose@programming.dev
            link
            fedilink
            English
            arrow-up
            2
            ·
            4 days ago

            Is porcelain inherently different from API?

            Completely distinct, yes.

            An API (Application Programming Interface) is specifically for application developers who are writing an application that interfaces with this system. By definition, this is not the action of an end user.

            An end user, on the other hand, is someone who cannot be assumed to know anything about the internals (plumbing) and needs a user interface that, ideally, hides all the plumbing entirely and presents an abstracted interface (a porcelain) that makes sense for the task they want to perform, regardless of whether or not the concepts there actually represent what’s going on in the plumbing.