Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The lazy Git UI you didn't know you need

bwplotka.dev

Post reply on HN
Print view View original

181–190 of 224 posts

Re: The lazy Git UI you didn't know you need

#181

Post by mertzdev »

prmph wrote: post #7

You might laugh, but in years of serious development, I have not come across a better git UI tool than SourceTree. If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried. Its file status and history view is…

I've been using SourceTree for years, mainly because I like the staging experience. I've never felt good about it though, I don't know why I've put up with the terrible performance for so long. I recently stumbled upon https://github.com/sourcegit-scm/sourcegit and it's totally replaced SourceTree for me. Very similar (or better) UI/UX but much more performant.

Re: The lazy Git UI you didn't know you need

#182

Post by haradion »

moron4hire wrote: post #173
duskdozer wrote: post #125

Earlier quoted context omitted.

If you could make it opinionated in one or two ways, how would you do it? I'm having a hard time thinking about situations that would be solved by this

Actually, the more I think about it, the more I realize the problem is that Git is too opinionated about a bad idea: attempting to make a DAG feel like a linked list in order to make it "easier" to use from the CLI because CLIs make it way too hard to visualize DAGs (don't come at me with your CLI DAG viz. Even the best ones are strictly inferior to the simplest GUI DAG viz). There are really only two things I care a…

> All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index.

It sounds to me like you want `git restore -W` and `git restore -S`.

Re: The lazy Git UI you didn't know you need

#183

Post by gwbas1c »

I just took lazygit for a spin:

In general, the tool looks cool. It also looks like it takes time to learn; but if you find it useful, it's probably worth it taking the time to learn.

There were two blockers for me:

1: I can't free-form select text with a mouse like a can in a terminal. (I honestly haven't used a TUI since the 1990s.) I frequently copy bits of branch names from the terminal, so this was a big deal for me. There is a way to "disable" the mouse in lazygit, which then allows copy & paste; but as I prefer to learn a program with point & click, it's a non-starter for me.

2: A lot of this functionality is built into Visual Studio for me. I use a mix of Visual Studio's point & click with git, and then the git command-line: Whichever is easiest for the specific task I'm doing. It just takes a bit more exploration in Visual Studio to find this functionality, as opposed to it being front and center when starting lazygit.

Re: The lazy Git UI you didn't know you need

#185

Post by unixplumber »

scotty79 wrote: post #107

After years of using git I got back to svn. Svn has one great feature, you can checkout (clone) repo partially. This way I can keep all my experiments in a single remote repo and easily pull any part of any project locally wherever I want. I don't really care about branching in svn. If I want to try variants of some code I still use git with multiple branches. I'm not sure what I would prefer for a team project. I'm…

One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.

Re: The lazy Git UI you didn't know you need

#186

Post by tcoff91 »

imiric wrote: post #143
tcoff91 wrote: post #85

Earlier quoted context omitted.

There is a new VCS that is a step forward (while being compatible with git). It’s called jujutsu.

Yeah, I disagree. I've read the Jujutsu documentation and a lot of praises for it, and its most compelling feature is a simpler UI compared to Git. There have been other VCS tools with arguably better UIs and feature sets than Git (Mercurial, Fossil), and yet they haven't gained traction, for better or worse. The only reason jj is having more momentum is because of its compatibility with Git, which was a smart decisi…

jj is not just a simpler UI. Its rebase is fundamentally more powerful than git, it has things like the operation log, first class conflicts, etc… that git doesn’t have.

Re: The lazy Git UI you didn't know you need

#187

Post by alwillis »

imiric wrote: post #65

Am I the only one who simply doesn't mind Git's CLI? Sure, it's rough around the edges, but I know those edges well. I sometimes do need to look up how to do something, but those cases are rare. Over the years I've accumulated about a dozen shell aliases and a modest `.gitconfig`, and along with a couple of helper tools[1][2], I can do 90% of what I need Git for in seconds. I truly don't need a fancy TUI, GUI, or any…

> Am I the only one who simply doesn't mind Git's CLI?

No, but by definition, Git's CLI doesn't scale for complex use cases. No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.

Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI. I get we don't use most of the options most of the time, but when you need them, they're not exactly discoverable.

    git commit alone has 40+ options:

    The `git commit` command takes **40+ options** in total. These include:

    - **Message options**: `-m`, `-F`, `-t`, `-e`, `--no-edit`
    - **Author/Date options**: `--author`, `--date`, `--reset-author`
    - **Modification options**: `--amend`, `--fixup`, `--squash`, `-C`, `-c`
    - **Staging options**: `-a`, `-p`, `-i`, `-o`
    - **Signing options**: `-s`, `-S`, `--gpg-sign`, `--no-gpg-sign`
    - **Output options**: `-v`, `-q`, `--dry-run`, `--short`, `--porcelain`, `--long`
    - **Advanced options**: `--allow-empty`, `--cleanup`, `--no-verify`, `--trailer`, and more
git help commit is over 4,000 words!

Re: The lazy Git UI you didn't know you need

#188

Post by alwillis »

scotty79 wrote: post #107

After years of using git I got back to svn. Svn has one great feature, you can checkout (clone) repo partially. This way I can keep all my experiments in a single remote repo and easily pull any part of any project locally wherever I want. I don't really care about branching in svn. If I want to try variants of some code I still use git with multiple branches. I'm not sure what I would prefer for a team project. I'm…

> After years of using git I got back to svn

You get the best of both worlds--a sane set of commands and a distributed version control system--by using Mercurial [1].

Checking Status: SVN: svn status Mercurial: hg status

Adding Files: SVN: svn add Mercurial: hg add

Committing Changes: SVN: svn commit -m "Commit message" (commits changes directly to the central repository) Mercurial: hg commit -m "Commit message" (commits changes to the local repository) and hg push (sends local commits to a remote repository)

Deleting/Removing Files: SVN: svn delete or svn remove Mercurial: hg remove or hg rm

Viewing History: SVN: svn log Mercurial: hg log

Viewing Differences: SVN: svn diff Mercurial: hg diff

Branching: SVN: svn copy (creates a branch by copying a directory in the repository) Mercurial: hg branch (creates a new named branch within the repository)

Reverting Changes: SVN: svn revert (reverts local modifications) or svn merge -r : (for more complex reverts) Mercurial: hg revert (reverts local modifications) or hg backout (to undo a specific commit)

[1]: https://www.mercurial-scm.org

Re: The lazy Git UI you didn't know you need

#189

Post by glenneroo »

alwillis wrote: post #75
xeromal wrote: post #20

I'm stuck on a mac these days and I miss Git Extensions, my favorite Windows git UI

There are several really good Git clients for macOS: 1. Fork: https://git-fork.com 2. Kaleidoscope: https://kaleidoscope.app 3. GitUp: https://gitup.co 4. Tower: https://www.git-tower.com/mac

SourceTree also isn't too shabby, though the interface is slightly different than the Windows version (for whatever reason).
Post reply on HN