I've got [a bit of neovim config](https://github.com/anlsh/nvim/blob/8b61520a5ecd752427abffc45...) which sends you straight to `neogit` (which is basically equivalent as far as I use it) when a certain env var is set.

So in my .profile I've got

``` alias gg="NEOGIT_SLAVE=1 nvim" ```

It's definitely not perfect but it's good enough to work for basic committing/rebasing flows and it's faster than booting up emacs for the same purpose.

I've used it before when I used to use emacs and it's really neat and simple to use but I think lazygit is better. I think of lazygit as the spiritual successor of magit. If you're curious what that looks like you can see a descriptive video on their GitHub.

He’s also saying that Magit is so good that he doesn’t recognise the complaints which motivate some people to switch from Git to Jujutsu.

FWIW, I agree. Jujutsu seems fine, but Magit is fine too. Maybe Magit is the Blub of version control, and Jujutsu would change my life for the better, but … I seem to be able to run in circles around my Git-CLI–using colleagues as it is.

1. I don't want to crate named branches. Keeping track of branch names is extra effort I don't need.

2. `jj evolve` is excellent.

3. First-class conflicts. Even just deferring conflict resolution later is convenient.

I am not an experienced magit user, (because I don't use emacs) so I can't really speak to this directly, but I can tell you what I understand to be the case.

Here's the motivation for jj, described by its creator (this will be on the FAQ in the next release:

The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.

Fundamentally, jj is a different VCS, not just a UI layer on top of git. And so there's a lot of differences, but they sort of sound more generic than specifically "vs what magit gives you."

I don't have time to be more lengthy at this exact moment, but I'll be curious to hear what others say, and I can come back and say more later if you're curious.

I find JJ to make things much easier for me than Git:

- No staging needed, edit your commit directly in your working directory

- Rebasing is automatic, I regularly edit historic commits and the messages

- jj absorb will automatically split and merge hunks into related ancestry commits

- Defer conflict resolution; many conflicts are resolved later by splitting/squashing/moving commits/hunks further (possible only for first-class conflicts)

- No interactive rebase needed, since jj commands automatically rebase while editing historic commits, it feels like constantly living within an interactive rebase

- Easily refer to the same revision (change) across rebase commands by using a jj change_id, without scribbling down Git commit hashes that change across a rebase

- Easily undo (+redo) your last commands through the jj operation log without having to backup the entire git repo at each step

And jj-fzf (https://github.com/tim-janik/jj-fzf/) gives me every useful jj command with a single hotkey (e.g. Ctrl-P for push, Ctrl-N for a new commit with 1+ parents, Alt-B to edit bookmarks/tags, Alt-R to rebase, Alt-Z for undo, …) while browsing the log with commit+diff preview.

Im using magit on windows for years now. It used to be that larger operations would completely clog everything up. They can still be annoying, but it’s not the dealbreaker it used to be.

HN is for nerds, the thing has "git" in its name, and you have access to Google.

Your move.

HN works by upvotes.

Lots of HN users like:

1. Emacs

2. Magit

3. Jujutsu

Just mention these three in a blog post and you'll hit the front page too!

have you tried lazyjj? I was thinking about giving it a go.

What is `jj evolve`? It's not listed as one of their commands.

I believe it was git that finally made me accept that my working memory is actually below average and that I’ve coped basically my entire life by leaning on my chimpanzee-like spatial reasoning and building mind [palace] for everything, especially architectural and network topology conversations (I became the reviewer and copy-editor for the network architect for a project I wasn’t even on because someone knew me better than I did). Graph theory works a treat with this so I become the de facto VCS surgeon. It’s “just” a big, fat, straggly, 4 dimensional tree.

I try not to torture anyone with it (VCS repair) who hasn’t already exhibited a knack for graph theory. I just tell them where the man traps are and to ask if they feel like they need to go there.

I agree, but partly for that reason I use fossil for most of my hobby projects. It is less stressful to not have so many features outside of the ones I use, and to not even have to be tempted to rebase or otherwise rewrite history as that is not supported.

For work and all my older hobby projects still only use git and I used that for ages and know it quite well, but that does not mean I always feel like I need to use it instead of something simpler.

(It is also FUN to use some other tool and not just git year after year. Got to learn something new now and then.)

This is a textbook example of damning with faint praise. If your VCS's interface is so bad that it motivates you to scale back your use of any nontrivial version-control features and instead just content yourself with rudimentary file syncing, that's a case against the interface. Either the additional features are useful and you're missing out on that benefit, or they're extraneous and are saddling the tool with unnecessary baggage.

I agree people should at least learn the happy path. It really is not hard at all and it solidifies the underlying concepts.

However I find there is a huge difference between me working solo on a repo or with one or two other people versus managing a complex project with 10+ developers and multiple SKUs in the same codebase (as an example).

That's when the "neurosurgery" aspects come in. Problems were frequently caused by junior devs making mistakes in their repo management that could be a headache to untangle (again, as an example).

You can get comfortable with it in 5-10min and after that you will slowly discover that it does absolutely everything you could wish for.

Today I'd honestly suggest to skip learning about git altogether (besides the basics, like branching, staging etc) and just start using lazygit immediately.

I've seen people claim that having a clean git commit history is not worth the time, it takes too long to have it nice etc, opting to just stuff their refactor, renaming and new feature changes into one commit. With lazygit I spend a few extra minutes a day to make it nice and I've gotten compliments for it from others when they review my PRs, because it makes the review much easier.

Second this. Put off trying it for years because "why not just use a GUI" if I'm going to leave the console anyway. Turns out lazygit is kind of a happy middle ground and using it actually feels better than it looks.

I really only use lazy git to review my code before commit it and I inevitably his the wrong scroll key and split the windows in half when I didn't mean to and I have to quit and restart to fix it.

That said, you'll pry that app from my cold, dead fingers.

Your comment caught my eye because as the de facto neurosurgeon, I’ve watched way, way too many UIs glitch a coworker into an impossible or unpleasant state and been the only one who didn’t immediately break eye contact. And remember they had someplace else to be. From CVS to SortaSafe to P4 to SVN. By the time I got to svn and saw the same issues I started spending political capital on convincing people to only use the CLI or maybe, maybe, JetBrains.

Usually the upvotes come from the casual users and the muttering from the heavy ones. In light of what I said, would you still recommend magit?

    - keeps the information similar to git cli
    - depending on the context it allows to use indirect features (chunk staging) live from the diff
    - for most use cases it will infer obvious flags/parameters from where you're at.

    e.g: if you're on branch and start rebasing, it will soft-infer the source and target branch.
    another one, in the log view, selecting a few commits and diff will get you the diff for that range

    it basically reify the informations from the output transparently for you and reuse it where useful, saving you input and efforts multiple times per day

    - lastly very low complexity so it's quick and out of your way. every time I have to pair, my colleagues say they couldn't follow what I did because by the time I started talking about staging/pushing, I'm already finished and back to source

I think they key to me is that it is really just helping you write git command lines. The menus are laid out exactly like the options of the relevant git sub-command, so that using Magit makes you more proficient at the CLI and vice versa. Other GUIs (including the awful ones that tend to be built into editors and IDEs) are instead hiding these details from you, so that if you are proficient at git on the CLI, you are still starting nearly from zero with the new interface and vice versa.

> I’ve been using Magit at work because it’s what everyone uses.

Where do you work?

The situation on windows is improved, not perfect but it is much better than it was.

It shows you conflicting files. I normally resolve each via ediff or my IDE and then go back to magit. It’s not a diff/merge tool.

Why don’t you want to learn emacs? It isn’t very difficult. It’s never worth it to avoid learning

You can choose to not learn Emacs and still use Magit. Any LLM will teach you the necessary config and then Magit is its own set of keybinds and everything.

You don't need to learn the JVM (beyond getting it installed) to play Minecraft and you don't need to learn Emacs to run Magit.

First, install doom emacs. Second, create a shell alias for "magit" that is bound to "emacs -nw -f magit". Then just run magit like any other TUI app - the fact that it's in emacs is easy to forget.

Or, if you're into neovim, there's Neogit, which is inspired by magit. And if you're not, there's https://github.com/altsem/gitu

gui app for linux with base magit features https://flathub.org/en/apps/io.github.aganzha.Stage

magit is the only thing I use Emacs for (well, sometimes I also use json-mode and json-pretty-print).

I prefer Spacemacs though.

Assuming you used neovim, did you try neogit? It promises to be a magit clone for vim, but I'm curious how faithful it is. I've never used magit, so I don't understand what's so nice about it. Would be interesting to hear a long time emacs user's opinion on neogit.

Its great for any git task. I think worktrees are often overlooked, magit makes it very fast to switch between worktrees. It’s great for debugging in two different commits in parallel and seeing exactly when some behavior differs.