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.