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.

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

    Magit: press l in the Magit window.

    The grain truck collision that is the Git command line is still visible in everything Magit does, and I can learn a lot by dipping into that. But I don’t need to look up the commands or combine weirdly disjoint options; Magit has a coherent, superior porcelain.

    • thingsiplay@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      9 days ago

      Interesting. So this is an Emacs extension it seems. Are the Git commands it produces usable outside Emacs?

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

        So this is an Emacs extension it seems.

        That’s right. I have taught many people to use Magit, who have then loved it so much they go on to learn Emacs :-)

        Are the Git commands it produces usable outside Emacs?

        Yes, Magit is a porcelain to Git, meaning that Magit uses Git commands as its internal plumbing. Any option you select is shown (de-emphasised) as the corresponding Git command-line option; and any operation Magit does, you can optionally pull up the window where it’s running the Git commands.

        This is a very good way to learn Git! The Magit interface is highly coherent and comprehensive, so it’s relatively easy to discover what you can do; and then you (optionally) look behind the scenes while it does it.

        None of this saves you from the burden of learning the mental model of how a Git repository operates. But at least you can learn that after getting your work done, by asking “okay and how did happen?”.

        • thingsiplay@lemmy.mlOP
          link
          fedilink
          arrow-up
          1
          ·
          8 days ago

          who have then loved it so much they go on to learn Emacs :-)

          Unfortunately I’m an evil Vim user. As for me, I’m not afraid of reading documentation and help texts. And in fact I love writing scripts and chain commands. But I’m at least always open to see what others do and use.

      • 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
            ·
            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
                ·
                20 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.