Do you use some GUI, TUI, terminal commands, plugins for other software?

Ideally, I want to find a cross-platform GUI app, preferably a FOSS one, and with as less overhead as possible, e.g. no Electron.

  • expr@piefed.socialEnglish
    17·
    6 days ago

    The git CLI. GUIs don’t get anywhere near what it can do, and the CLI is scriptable and can easily interop with other programs.

      • expr@piefed.socialEnglish
        2·
        5 days ago

        Not sure what you’re saying. Are you saying you need GUIs for diffs? Because that couldn’t be further from the truth. Unified diff itself is highly underrated (and my preferred form for many reasons), but even if you wanted side-by-side diffs, there are many ways of accomplishing that without a GUI. That’s the entire point of git difftool.

        • iegod@lemmy.zip
          1·
          5 days ago

          What I’m saying is that performing a diff via command line isn’t something that brings as much utility as using a GUI. You can do it, but a major part of this utility is the visual aspect, layout, navigation. CLI tools don’t come close to what I want. Isn’t difftool meant to be used in GUI form? Am I missing something here?

          • expr@piefed.socialEnglish
            1·
            5 days ago

            The default difftool is vimdiff, which is not a GUI program. But no, the point of difftool is to iterate through files to diff and pass the different versions to an external program. There are many external CLI and TUI diffing programs. The point, though, is that the git CLI is still the driver of everything and you still have the full range of options available to git diff, rather than some GUI program being the driver, which are universally limited in what they can do.

            Personally, I load regular git diff output into a vim buffer via :read. Unified diff is largely superior to side by side diffs, IMO, because most of the time, changes in one file are accompanied by changes in a number of other files, so it’s useful to be able to quickly follow a thread of changed calls or whatnot. And with unified diff output, you can see and manipulate hunks directly.

  • DavidP@lemmy.world
    2·
    5 days ago

    I have some handy aliases so I use CLI most of the time. And on my gaming keyboard I have the side macro keys set to:

    • git status
    • git diff
    • git add .
    • git commit - m “”" (with the cursor left into between quotes)
    • git commit -am “”

    For merge conflicts I’ll use whatever the IDE provides.

  • FizzyOrange@programming.dev
    5·
    6 days ago

    I found this one recently which is really good:

    https://github.com/sourcegit-scm/sourcegit

    Much better than most of the standalone Git GUIs, even the commercial ones.

    However I don’t actually use it, because I use VSCode and there’s a great extensions called Git Graph that integrates nicely into it. It is abandoned unfortunately but it still works fine so I still use it.

    Here’s my rating of all the Git GUIs I’ve tried (that I remember):

    • SourceTree: works ok but just so incredibly slow.
    • GitKraken, SmartGit, Tower, Sublime Merge: Commercial and I don’t like the UX of any of these.
    • Git Extensions: This one is actually really good. Terrible name though. Also kind of Windows-only.
    • GitX: This is also really good but unfortunately it’s one of those pieces of software that has forked into dozens of half maintained versions that you’ll need to spend hours in phpBB forums figuring out which one to use (like TomatoUSB). Also Mac only.

    I never tried Magit because TUIs are dumb.

    Also don’t listen to anyone that says “just use the CLI”. It’s okay once you’ve learnt how git works, but even then you’re still going to want a way to view the commit graph. Learning Git without a GUI is needlessly masochistic. Once you have learnt it you can start mixing it up with the CLI.

        • Tempy@programming.devEnglish
          1·
          4 days ago

          Fair enough. I don’t tend to use it all that much. But it is there. I tend to find I don’t really need to see the graph all that much. Maybe because I’m mostly working in small teams. It’s just not that important to my understanding of what’s going on.

  • mcmodknower@programming.devEnglish
    7·
    6 days ago

    i use the standard git cli mostly, and sometimes the magit package for emacs (but only when i am also working in emacs already)

    • Kissaki@programming.devEnglish
      3·
      6 days ago

      pen and paper is decentralized storage too, but the push and fetch sync protocols are a lot of work

  • fibojoly@sh.itjust.works
    1·
    4 days ago

    I just used whatever my company would provide, and since I changed company quite a bit, and SVC software with it, I never really learned anything beyond add, commit, push/pull (seriously) for the last 18 years. Then this winter they asked me to teach advanced git, so I went ahead and learnt all the fancy commands and I’m thoroughly enjoying the CLI with command completion.

  • sip@programming.dev
    3·
    6 days ago

    i use git. got a tree alias a tree-like log. and an amend alias to add changes to the prev comit to keep the message

  • JackbyDev@programming.devEnglish
    2·
    6 days ago

    I use git in the terminal. On Windows I used git for Windows. I even used that MSYS CLI it provided as my daily driver terminal.

  • Kissaki@programming.devEnglish
    2·
    6 days ago

    I’ve been using TortoiseGit since the beginning, but it’s Windows-only.

    In TortoiseGit, the Log view is my single entry point to all regular and semi-regular operations.

    Occasionally, I use native git CLI to manage refs (archive old tags into a different ref path, mass-remote-delete, etc).

    Originally, it was a switch from TortoiseSVN to TortoiseGit, and from then on, no other GUI or TUI met my needs and wants. I explored/tried out many alternative GUIs and TUIs over the years, but none felt as intuitive, gave as much overview, or capabilities. Whenever I’m in Visual Studio and use git blame, I’m reminded that it is lacking - in the blame view you can’t blame the previous versions to navigate backwards through history within a code view. I can do that in TortoiseGit.

    I’ve also tried out Gitbutler and jj, which are interesting in that they’re different. Ultimately, they couldn’t convince me for regular use when git works well enough and additional tooling can introduce new complexities and issues when you don’t make a full switch. I remember Gitbutler added refs making git use impractical. jj had a barrier to entry, to understand and follow the concepts and process, which I think I simply did not pass yet to have a more accurate assessment.

    I did explore TUIs also as no-install-required fallback alternatives, but in practice, I never needed them. When I do use the console, I’m familiar with native git to cover my needs. Remote shell: native git, locally: Nushell on top of native git for mass queries and operations.

  • ulterno@programming.devEnglish
    2·
    6 days ago

    git gud :P

    I use the CLI mostly.
    It gives me confidence that I am not doing something unknowingly.

    In some cases, I prefer GUI tools:

    • For blame, I prefer what Qt Creator provides
      • Although it could have been better
    • For graph, the default CLI one is not pretty enough and honestly doesn’t help as a graph. So I go with GUI stuff
      • there are quite a few alternatives available that make it much faster to grasp on sight