Don't miss "Staging parts of a hunk", which is Magit's killer feature, IMO. You can easily go through your current diff (from staged) and add/remove single lines from the staged delta.
I hate to start sounding like a shill for this app, but this is also one of my favorite parts of https://git-fork.com/. When you are looking at changes you can easily stage any lines you want. I am able to work on multiple feature branches at the same time this way: you can make all the changes at one time stage only the lines you need for this branch commit, switch branches and repeat. It’s also great on a single branch when you want to make the changes as you go but want to commit things in more logical groupings. Helps for example when you are refactoring a few functions and want to stage each piece separately.
It's okay. Every time there's a discussion about Magit, people bring their favorite Git GUI to tell everyone how stoked they are to use it. I myself have tried several of them. However, majority of those apps are like Steve Yegge would put it: "are cookie-cutter solutions". Whenever you need a quick way of doing something that's not built into the tool, you have no option but to submit a feature request and wait. Sometimes wait for a very long time. With Magit you can just do it yourself. Emacs lisp is not super difficult to pick up. Besides, there are bunch of forums where people would happily help you.
One small example: I needed to see log of commits since the last pull, basically `git log ORIG_HEAD..HEAD`, but in a way that's compatible with Magit, otherwise I would just do it in the command line. It's not something that people would do very often, it's not usually built into the client. To get something like that to work with Magit, literally takes a single line of emacs-lisp.
Even that is something that Fork probably can handle with custom actions: https://git-fork.com/blog/page/3/#custom-actions. I agree that a lot of the times apps are mostly cookie cutter and Fork may not really be all that special, but it definitely feels like the devs try to make the common path easiest, but make it pretty simple to take the desired path without friction.
Works on generic diff buffers, and is not tied to git specifically. And you can just edit the diff buffer, which gives you infinite flexibility. Since emacs already has vc mode, the only extra thing magit does is rebasing. For everything else, vc-mode and commit-patch are superior.
Sounds like you haven't used Magit very much. Browsing the manual for a few minutes, or looking at a screencast or YouTube video, would show you how much more Magit does than what you described.
Regarding commit-patch specifically, its readme says that, to commit parts of a patch in separate commits, hunks must be "killed, split, or edited" into separate patches.
Magit is obviously superior to that: with a few keypresses, hunks in the working tree can be staged, hunks in the index can be unstaged, etc. Unstaged changes in the working tree can quickly be sliced and diced and committed separately. Individual lines can be staged or unstaged by selecting them visually. Magit can even automatically back up changes at each stage of the process into special branches, so if you realize, hours or days later, that you accidentally discarded some code without committing it, you can easily retrieve it.
Magit is the most powerful, efficient version control tool. See for yourself: https://magit.vc/
You have no idea on how many levels that statements is false, there's much more than just the rebase:
- You ever needed to see branches in a specific order, sorted by committer-date?
- What about filtering them, maybe showing only those that yet not merged to master?
- What about ordering commits, searching through them, etc.
- You ever wanted to see all the commits authored by you that are at least two months older?
- Ever needed to see commits that only include a specific set of files?
- What about tracing the evolution of a given function?
- Bisects, have you ever done those?
- You ever had a stash that you can't pop because you made changes, and now you have to resolve conflicts?
- Have you ever thought about cherry-picking a specific line from a stash, another branch, etc.?
- Ever needed to work with submodules?
- Ever thought about how nice would it be to issue a Pull request without leaving Emacs?
I'm not sure when was the last time you tried Magit, but maybe try again. Perhaps then you'd appreciate how much good stuff people built into it. It's impressive because aside from a single (hugely successful) Kickstarter campaign and some small voluntary contributions, maintainer and contributors don't get paid for the fantastic work they do, and your comment in that context sounds a bit disingenuous.
Staging (and committing?) parts of a hunk is cool and I have done this many times myself. However, I am always uncomfortable with it because I am unsure how to incorporate it within the overall workflow. I'd like each commit of mine to at least compile and pass some tests.
So what's the problem? Commit often, make a bunch of commits. Or commit into the same commit over and over (<c e> - extend). Then depending on level of granularity you can either group related things together, or break one big commit into a bunch of smaller ones.
Rebasing with Magit is a joy, it feels like you're a tailor and you just need to cut the fabric into nice pieces, and if sometimes things get too big or too small, you can always quickly fix it. And even when it feels that you accidentally ruined everything, you can always look at the reflog and un-ruin everything back to normal.
The custom buid system we use at $WORK can build and run tests from the index (or any git revision really) specifically to facilitate fine grained commits.
I actually use emacs git-gutter to have a more visual way of seeing what's going into a commit or not. Having the inline annotations in the files I am working on it is great for doing the staging parts of a hunk.
Well, in Magit buffers that show diffs you can do refinements (see exact portion of changed thing in a line highlighted, not just the whole line). You can choose different diffing algorithm, ignore whitespaces, expand or narrow the context (i.e. it shows lines that changed, but you don't see the function header), detect renames, etc.
Git Extensions and Git Cola (possibly other GUI clients I haven't used) have the ability to view a diff and stage individual lines from it. Unfortunately they don't let me reorder lines in the diff.
Tig is the only other tool I’ve used which comes close to the speed and capability provided by Magit. I’ve recommended it to many people who don’t want to learn Emacs for one reason or another.
It's nonlinear. With `git add -p` you can press keys to go back and forth through the hunks. If there are a lot of them then it can get tedious. With Magit, on the other hand, you see everything in a window and you can use all of your usual emacs commands to scroll/search that window, and then hit the key to stage the hunks as you desire.
You can do this with `git add -p` as well, except maybe not trivially (ha). There's the 's' command to split hunks into smaller ones, and then there's also 'e' to open the patch in your editor where you can change the raw patch to whatever you'd like, although in my experience editing it correctly is not straightforward.
I've just recently started using the `e` (edit) command in `git add -p`. It takes a little bit to get used to writing "correct" patches, but it's super powerful and I'm using it surprisingly often now.
> I guess it might be really effective for those who know emacs.
You don't have to know Emacs to use Magit. People often try Magit, usually because someone shows them the workflow. They don't even want to learn Emacs to begin with, but Magit looks awesome.
But like it was noted in the comment a few levels above - Magit's workflow is nonlinear. It doesn't feel like you're switching from one activity to another. Even when rebasing (which is very transactional), you still can peek into things in other branches, stash and un-stash, resolve conflicts, etc. World doesn't have to freeze just because you're doing "git add -p".
I'm sure magit is nice. It's just that everything you list as nice things about magit are in vanilla git as well. Maybe you prefer the presentation in magit, that's fine. The point is to be fully aware of the available options - which the author of the article doesn't seem to be, as they only compare against git add -p, not against git gui.
The one thing that's truly missing in vanilla git as far as I know is the ability to edit the index directly, without editing the checked out files. (Does magit allow that? It's not an advertised feature in the article as far as I can see...)
> nice things about magit are in vanilla git as well
Magit is not trying to replace Git, it's not pretending to be something else. You still have pretty much everything what's in Git. You can still use your aliases and run vanilla git commands. So why do you need Magit? For efficiency. You don't care about your efficiency? Fine. But please don't make conclusions that the advocates of Magit don't know better. We have tried other alternatives and we have used git command line.
> ability to edit the index directly, without editing the checked out files
What? I don't think I understand what you're asking for here. You stage parts of a file or the whole file. It shows up in "Staged changes" section of Magit buffer. You edit the file, save it, parts that are diverse now will be shown within "Unstaged changes" in a nice diff. You may choose to stage new changes, you may resolve conflicts in a three-way-merge window, discard your changes (staged changes remain), etc.
Why would you want to edit staged parts without modifying the file itself? I don't get it.
It happens to me with some regularity while massaging large patch series via rebase.
The common pattern is that as a consequence of squashing, rebasing, and so on, an early patch in the series has a bug / compile error that is trivially fixed in the next patch in the series.
In those situation, you have to fix the first commit in a middle of a rebase, but keep the result _after_ the next patch the same. This can currently be done by making the change, immediately reverting it, and then squashing things together again. That is, before you have:
o -- A -- B
Then:
o -- A -- F -- F^{-1} -- B
Then you squash A and F and F^{-1} and B to get:
o -- A' -- B'
Having a more convenient way of doing such fixups would be nice, and I think being able to edit the index directly would help in some of them.
With Magit I wouldn't even need to do that. I would just snapshot the file * and continue changing it, then when I need the original version of it I would just pop it out off the stash.
So let's say you stage a few different things. Then run linter/code formatter/etc. You can see the changes done by the linter, you can refine the diff (so it shows not only the lines that changed, but also highlights the details), you can expand/narrow the context (for example if you can see the change, but can't see the function header and without it it's confusing). Then you can [selectively] stage those changes.
What about if you overwrite a few lines of something and now the original only exists in another branch? You can peek into that thing, check the diff, even jump into the version in the other branch (without having to check it out) and selectively "cherry-pick" lines of code.
It's a seamless workflow, it doesn't feel like you're doing one thing at a time, it feels more natural and doesn't require undivided focus like: "no, I can't afford a bathroom break right now, I'm in the middle of staging, goddammit."
Awww thanks, all of us who use Magit will switch back to git-gui now.
Seriously, it's not a competition of which git-client has more features.
Magit is much more than just "I can do that" thing. It is extremely efficient, it allows (probably) the most efficient git workflow that can be extended and customized.
It's not the most beautiful thing - the same thing can be said about an industrial excavator. But do you want a beauty or the efficiency? (You want beauty? download GitKraken or something) Can you imagine if someone removes all the controls inside the said excavator and replaces them with a single iPad like device in the middle of the dashboard? Yah, perhaps it'll be aesthetically pleasing, but would it be efficient, even if it has access to all the features and digging modes, etc.?
If you don't care about the efficiency of your git workflow, fine. But if you do, take my word for it, trust me - you wouldn't find a better way to deal with Git than Magit.
That's a partial hunk staging, not line-by-line based. Read the comments. IntelliJ doesn't seem to support that feature, yet (or still). I have used IntelliJ for about seven years. It does have a superb Git integration. That was the only reason why I couldn't switch to Emacs (for a very long time). I refused to believe that anyone could do better than that. I was wrong.
Isn't this what Pijul does, but at a fundamental level, instead of having an extra level of abstraction on top of the snapshot-based git, and can therefore do it even "after the commit has been pushed" ?
Pijul, Mercurial, SVN, Fossil, TFS, ... Who cares? Git has won. Either we like it or not, but we're stuck with it for a long, long time. Ping me when Github starts supporting Pijul repos. I'll send you 20 bucks or something.
Remember when XML had "won" too? Then JSON came around...
Remember how Windows "won" ?
I won't ever use Github now (how are you going to export all those non-git features like tickets when github is not desirable anymore, hmm?), and neither should you if you care even a tiny bit about open source software !
> Remember when XML had "won" too? Then JSON came around...
JSON wasn't a very well-thought idea, we tried to "fix" it with yaml (which turned out to be even worse), compare it with EDN (which is far better, but sadly nobody outside of Clojure community uses much)
> Remember how Windows "won"
Windows still dominates desktop OS market and we're still waiting for "Year of Linux on the desktop". Every year some people claim it to be "this is it", but in reality, it is still far from becoming reality. With WSL now even long-time Linux users are tempted to go back to Windows. And honestly I personally don't like that.
My point is - "worse is always better" *
As I said: either you like it or not - we're stuck with Git and now with Github too.
