Unfortunately, for most people the fact that it's part of Emacs is a blocker.
And because most people use worse Git tools, they tend to use workflows that are easier with more cumbersome tools; generally just committing all kinds of junk commits to a branch, and using the "squash and merge" feature of GitHub or GitLab to clean everything in a PR/MR up into a single commit.
So yeah, it's sad that people don't use Git to its full potential because almost no other Git interface works as well, and most people aren't going to learn Emacs just for a Git UI.
> Unfortunately, for most people the fact that it's part of Emacs is a blocker.
OT but i've learned the hard way not to push people into emacs.
a few years ago i made the very stupid mistake of pushing some colleague to trying/learning emacs and then i found myself having to explain the same person everything as well as fix his elisp code from his ~/.emacs .
Reality is, i didn't want to have that role and that colleague wasn't interested in gnu emacs in the first place.
That was a very stupid mistake on my side.
Nowadays i just say things like "yeah it's magit, an emacs plugin" or "ah yeah, it's nice because you spend some time learning it and then you can bring it over from company to company, no licenses involved or other annoyances".
Some people are intrigued, most other absolutely aren't... And it's fine.
Surely the mistake here is conflating "learning Magit" with "learning Emacs"? I can run Java applications while knowing nearly nothing about the JVM. The same is true for applications based on Emacs.
Magit is not an "application based on Emacs", it's an extremely powerful git plugin for someone who is already using Emacs. If you're not using Emacs, it would be crazy to fire up Magit just to do a git commit or rebase. Even the fact that you'd have to learn Emacs' extremely idiosyncratic keyboard shortcuts, and even keyboard shortcut help (what do you mean "save is C-x C-s?" what does that even mean?) is a huge problem not worth the effort.
And I'm saying this as someone who has exclusively programmed in Emacs with Magit for the last 5 years in my job.
I simply used Emacs for 25 years, avoiding editing .emacs entirely
Only in the past years have I started customizing it
My attraction to Emacs is stability and I can use it in text or GUI mode.
Many editors have come and gone in that time, many employers insist I use this or that piece of over designed, under done GUI. When I have the chance, back to Emacs
Peculiarly, having used Emacs for a decade as my main editor, and Git for much more than that, I never could get used to Magit.
Maybe it's due to muscle memory from my CLI Git setup (nothing special, just some aliases, scmpuff, delta, etc.), or Magit forcing you into its own quirky UI, but it never clicked for me. For 99% of things I use Git for, I don't have any issues with my workflow, nor wish to improve it. For the other (very) rare occasions, I can always ask an LLM to help me figure out the right command.
This is also why I don't see any value in Jujutsu either, or any of the GUI/TUI wrappers. The Git CLI porcelain with some minor customizations just hasn't been a problem I need solving.
I've looked at Magit and indeed Emacs is a blocker as it's not something I'd like to pick up and maintain. I am using Fork as my primary Git GUI and am pretty happy with it. Lazygit and tig cover the few use-cases which Fork does not cover.
I am not someone to recommend VSCode, but if you are already using it, you could check out edamagit. I think in the Vim world there is also some equivalent.
Good tools can improve your workflow for sure, but it's easy enough to keep a clean history with a handful of git commands. There are two main reasons people don't do so: 1. they don't know the commands yet or 2. they just don't care (and are in an environment where there's no incentive to care).
The kind of person who would try a tool like Magit and use it to discover git would have found a different route if Magit didn't exist. The type of person who doesn't care isn't going to learn something just because a tool is available.
Personally i've been often looking for an opensource Git GUI front end but couldn't find anything i'd like. My points of reference of decent tools -ignoring the underlying tech- are Perforce and TortoiseSVN under Windows and Fuel[0] (for Fossil) and KDESVN under Linux.
Perforce and Fuel are the two i like the most, followed by KDESVN and Tortoise. But since i'm on Linux and i stick with opensource projects, Perforce and Tortoise are out, leaving me with Fuel and KDESVN. I'm using KDESVN for a few projects where i don't care about external collaboration and want to store many binary files (which Subversion does it better that Git IMO), though KDESVN is very primitive and limited in what it supports (it doesn't support shelving at all, for example - in fact for anything beyond commit and checking the history you probably need to use the cli tool). I do not use Fossil much nowadays but i used it a lot in the past so i have a bunch of repositories in it, for which i use Fuel. Fuel is unfortunately not being developed anymore, though since it is opensource it doesn't matter much (which is a reason why i ignore anything non-opensource, i know there are some decent proprietary Git clients but for me they might as well not exist).
I think at some point i'll grab libgit2 and make something using Lazarus, probably something similar to Fuel. Unlike libsvn, which seems to be made in hell, libgit2 seems very sane and shouldn't be terribly hard to make something usable out of it.
In the meanwhile i use a combination of git cola, gitgui and gitk though they all feel like a hodgepodge of barely thought random features thrown in together (and i hate that they all want to impose their own idea of how i should format a message -especially git cola- which of course aren't identical between of them and aren't even close how i'd like to format the messages myself).
Isn’t this just something that any IDE has built-in these days? Maybe I’m missing something, but how is this fundamentally different from the built-in git timeline view from something like VSCode or Jetbrains?
> Isn’t this just something that any IDE has built-in these days?
In most IDEs I feel that Git integration is an awkward badly integrated afterthought. They are also very much tied to the whatever IDE offers them in terms of available shortcuts, layouts, controls etc. (this applies to Magit, too).
I upvoted you because you were unfairly downvoted. I don't even use a Mac any more after 20 years of exclusively using them but it's actually hilarious how bad magit is compared to this. It's all well and good making the most of limitations that are self imposed but people need to remember to look outside their own bubble.
It may be prettier looking. I've seen many Git GUIs that are prettier than Magit.
But none of them that I've tried have ever come close to the workflow.
I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.
Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
So no, I haven't tried that one because it's Mac only, but I'm not really seeing from the screen recordings the kind of workflow that I find so powerful in Magit.
> I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.
I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts.
My most common workflow besides staging anything is (to make sure history is clean):
- split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit)
- move new commit up/down the branch (doesn't require interactive rebase in GitUp)
- squash up/down
(undo/redo from time to time)
As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent
> Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2]
However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason.
I cannot imagine how you can properly supervise an LLM agent if you can't effectively do the work yourself, maybe slightly slower. If the agent is going a significant amount faster than you could do it, you're probably not actually supervising it, and all kinds of weird crap could sneak in.
Like, I can see how it can be a bit quicker for generating some boilerplate, or iterating on some uninteresting API weirdness that's tedious to do by hand. But if you're fundamentally going so much faster with the agent than by hand, you're not properly supervising it.
So yeah, just go back to coding by hand. You should be doing tha probably ~20% of the time anyhow just to keep in practice.
Kind of agreed. I like vibe coding as "just" another tool. It's nice to review code in IDE (well, VSCode), make changes without fully refactoring, and have the AI "autocomplete". Interesting, sometimes way faster + easier to refactor by hand because of IDE tooling.
The ways that agents actually make me "faster" are typically:
1. more fun to slog through tedious/annoying parts
2. fast code review iterations
3. parallel agents
Yeah. I've been finding a scary number of people saying that they never write code by hand any more, and I'm having a hard time seeing how they can keep in practice enough to properly supervise. Sure, for a few weeks it will be OK, but skills can atrophy quickly, and I've found it's really easy to get into an addictive loop where you just vibe code without checking anything, and then you have way too much to review so you don't bother or don't do a very good job of it.
It’s a useless skill to keep sharp. It will never again be important. It’s like the electrical engineering professors who insisted we needed to understand how the circuitry worked in order to be good programmers. We didn’t.
I mean, there's also the whole GitHub free tier. It used to only be for public repos, so mostly OSS plus "shared source", but now they allow it for private as well. But it still costs them money to host your code and provide CI minutes.
What do you mean it's unfit for training? It's a form of reinforcement learning; the end result has been selected based on whether it actually solved the need.
You need to be careful of the amount of reinforcement learning vs continued pretraining you do, but they already do plenty of other forms of reinforcement learning, I'm sure they have it dialed in.
Oh, I do frequently have biscuits and gravy topped with fried eggs, though the biscuits and gravy would definitely pull it further towards the flour end of the spectrum, maybe not quite in the dark region.
Also, hollandaise is pretty integral to eggs benedict, I've had lots of variations but the traditional with poached egg, canadian bacon, english muffin, and hollandaise is really by far the best.
Are we counting butter as milk? Because hollandaise sauce is an emulsion of egg yolk, butter, and lemon juice, so no milk directly unless we count butter.
Qwen3 Coder Next in llama.cpp on my own machine. I'm an AI hater, but I need to experiment with it occasionally, I'm not going to pay someone rent for something they trained on my own GitHub, Stack overflow, and Reddit posts.
Fees have historically gone up above $100 per transaction. They've since added hacks on top of the original Bitcoin protocol to get the price back down again, but the original design was not good for low fees.
And transactions can take 30 minutes or more to settle, that's hardly instant. If you accept a transaction instantly, it's relatively easy for someone to scam you by double spending.
So, no, Bitcoin doesn't make a great digital cash. Maybe a better wire transfer. But the biggest benefit of it is to be unblockable and unrefundable, which makes it great for scames and illegal activity, plus the speculative nature of the pricing, which is great for gambling on.
Pointing at the BTC transaction fee and saying it is super expensive is like pointing at a problematic car model and saying all cars are bad.
There are any number of other popular coins out there that have the same or better liquidity as BTC that charge tiny fractions of the fees. And also settle in seconds.
You're saying Bitcoin like BTC, but the parent commenter was probably referring to the giant ecosystem of coins, that happens to include BTC, but also many other much faster and cheaper options, that are used to globally remit payments every day.
What it's replacing, by the way, Western Union, Wise and the like, is also pretty unblockable and unrefundable.
What? I was replying to someone who explicitly referenced the Bitcoin whitepaper, they were clearly talking about BTC. And the protocol from the whitepaper was actually pretty bad, from a cost and transaction time point of view. It's gotten a bit better with some hacks layered on top of it.
And yeah, the thing is, payment systems that work approximately as well as BTC exist without being cryptocurrency and using up so much electricity on mining. The main difference is that they don't operate in some areas where BTC still can (like evading sanctions, like this), and the speculative nature of BTC (which is actually a net negative on using it as a cash).
What’s your point? That BTC was the first and it has these flaws? Ok, fine, but that also doesn’t discount the point being made here which is that shitcoins DO have an actual use case that people are using them for in the real world. It might be the only actual valid (legal) use case, which is kind of what some other responders implied, but it doesn’t mean that there is no value.
If payment systems that aren’t shitcoin based are working just as well, then why are these coins absolutely destroying the incumbent players like Western Union in the remittance space? If the existing solutions are good enough you wouldn’t expect incumbents to be taking such a beating here right? The systems are equivalent enough? WU does for instance 100B ish a year currently, which is around 12% of the global market. A fat share of that global remittance market is… checks notes… crypto based remittances.
I’m all for trashing the next shitcoin. Don’t mistake me for some crypto apologist. I personally don’t own or use them outside of narrow use cases where they are a transient thing that gets liquidated into actual fiat as soon as possible. It’s a world ripe for fraud and abuse and the whole concept of shitcoins is probably not great for society. But to take some poorly thought out implementation that was,
mind you, the first attempt at actually doing this in the real world, and try to extract it to some general conclusion that the technology is not useful 15 years later is just patently false. If the alternatives you mention are so great, why are they not winning on mindshare worldwide? Certainly seems like crypto is winning in the remittance space.
They've since added some hacks to enable it to handle more transactions and bring the price down. Effectively, the network had hit its limit on the number of transactions it could fit in a block, so you had to pay high fees to get accepted in a block, the miners simply couldn't accept all transactions; but they've added ways of fitting more transactions into a block that have helped drive prices back down again.
So now it's back to being cheaper than Paypal, but yeah, there was a time when there were $100+ transaction fees. And it may hit that again if transaction numbers go up enough to fill up blocks with the new implementation.
High tx fees are an essential goal in Bitcoin's design: in the long term, when the block subsidy becomes insignificant, Bitcoin's security will rely almost entirely on tx fees.
The thing is, in our current legal system, property rights are fairly fundamental; they own certain things, and that gives them a legal right to control it. And the money they derive from that has become more and more influential in our politics, to the point where they can influence a minority share of voters who have outsized voting rights, while also suppressing the votes of other voters, to achieve minority rule.
Without a vast reshaping of our sense of property rights, taxation, and redistribution, it's hard to see how this would change. And it's becoming increasingly hard to see who that vast reshaping could happen via peaceful, civil means.
But part of the faith is faith that God can communicate through imperfect mortal vessels.
> Moses said to the Lord, “Pardon your servant, Lord. I have never been eloquent, neither in the past nor since you have spoken to your servant. I am slow of speech and tongue.”
> The Lord said to him, “Who gave human beings their mouths? Who makes them deaf or mute? Who gives them sight or makes them blind? Is it not I, the Lord? Now go; I will help you speak and will teach you what to say.”
Like, that's the whole deal about all of the prophets, popes, priesthood in general. They are all mortal and imperfect, but God still speaks through them.
Unfortunately, for most people the fact that it's part of Emacs is a blocker.
And because most people use worse Git tools, they tend to use workflows that are easier with more cumbersome tools; generally just committing all kinds of junk commits to a branch, and using the "squash and merge" feature of GitHub or GitLab to clean everything in a PR/MR up into a single commit.
So yeah, it's sad that people don't use Git to its full potential because almost no other Git interface works as well, and most people aren't going to learn Emacs just for a Git UI.