What is Reddit's opinion of
Magit?
From 3.5 billion Reddit comments
70 reviews of this app found across Reddit:
Magit is hands down the best git experience I've had, even though it's not
really a GUI. Most GUIs and text editor extensions miss a lot of features (like
git reflog, patching and advanced rebasing) but Magit seems to have it all.
Elvind Fonn's Spacemacs ABC Series A lot of tricks I didn't know I could do easily before, and upon seeing it I knew it would improve my efficiency vastly: find pattern in all files in a project (SPC s p), iedit (SPC s e), handle multiple projects with projectile (SPC p l), quick navigation and preview with ranger,
Apart from org-mode, magit is another killer feature for me. Git's native command line is unnecessarily complex. It's difficult to perform line-based commit, ediff, rebase without typos, and soon I lost patience. Now with magit, VC becomes such a breeze. I don't miss the days I tried aliasing in .zshrc or git config.
Also just discover ledger. And oh yes, it's wonderful.
Git itself is much faster on *nix than it is on Windows (and Magit makes lots of calls to Git). On OSX process forking via Emacs was slow before Emacs 26, but I gather that Magit performance on OSX should be fine from that point onwards.
You should read https://magit.vc/manual/magit/Performance.html
GNU/Linux is great, though. Go ahead and dive in! Once you've become accustomed to it, you may wonder how you coped in Windows for as long as you did.
Yes, a sensible answer to Magit "getting worse and evolving in directions that I want nothing to do with" would seem to be "use a version that you liked".
Whether that's https://magit.vc/elpa/v1/ or some other 1.x or 2.x version, there's nothing preventing you from committing a particular version of Magit to your personal config and using that henchforth (or using it as a basis for your own improvements, if you so wish).
...4. Change jobs ;)
For clarity, Magit 1.4.x (refer to https://magit.vc/elpa/v1/ ) supports Git 1.7.2.5+
Magit 2.x up until the current 2.13 release requires Git 1.9.4+. Starting from Magit 2.14, Git 2.4+ will be required.
So when you say "Magit refuses to run with 1.7.0" make sure you're actually testing with Magit 1.x? Your version of git is still unsupported by 1.4.x, so perhaps it still won't work; but it's far more likely to work than if you're attempting to use Magit 2.x.
The next option is to go back in the Magit 1.x history until you get to a revision which supported Git 1.7.0, and install that in Emacs. The ELPA repository provides version 1.4.2, and I've checked that 1.4.0 likewise specifies Git 1.7.2.5+ in its README file. The next version back is 1.2.2 which does not appear to indicate a minimum Git version in its README, so I would suggest trying that version if you have no success with 1.4.2.
Magit 1.x is pretty old, and it is far less sophisticated than the current version, but it's still awesome compared to using the command line, and still provides some of the killer features that Magit users love.
But what I really wish for is a tool to interact with any git forge, e.g. to create PR's issues etc. for github, gitlab, bitbucket, sourcehut etc. In emacs, I use the excellent magit git porcellain and via magit forge it allows for PR and issue creation and editing across a couple of forgest, though it's missing support for some other things that gh can (e.g. repository creation, though I think there are other emacs package for that, I just didn't use those yet). But I'm aware emacs is not for everyone and something like a cli tool that works across forges would be nice. Maybe there is, I didn't do any research yet. But since the different forges have different features, I admit that a github-specific tool will be more powerful.
I like the github UI and what it did to boost open source software development by facilitating collaboration, but I don't like monopols and want to avoid lock-in, which is I want to use other forges more when possible.
I would say the most useful place to start with Magit is the Prefix Commands. Each of them will show a little interactive panel indicating what options and actions are available, and what keys to press to trigger them.
Another good reference is the official Reference Card.
The main thing you need to get accustomed to is the prefix keybindings, and play with them in a magit-status buffer. Once you have the basics down I think you’ll rarely wanna reach for the git CLI.
Personally I haven’t used (or felt the need use) the git CLI for years. I think Magit the UI around for working with git. If I somehow ever switched to different text editor, I would still use Emacs just for Magit.
Both. I use magit (https://magit.vc/) which is built into emacs and is available as a terminal and gui app. Since it's a git porcelain it can do everything the cli can do, usually with single letter commands.
Just to let you know, if you want the keybindings from vim without all the other packages that Doom brings, you only need the Evil package. I also switched from vim to emacs and Evil was very helpful for me. Another recommendation is magit if you work often with git. It's my favorite interface for git management.
>I know that the Magit project recently added functionality for interacting with remotes but I cannot find reference to where that code lives
Sounds like you're thinking of Magit Forge, but it doesn't do what you're asking.
The solution in /u/magnusmalm no longer works, however it's gotten simpler now. The --since/--until commands are now built-in, but hidden by default. After pressing l to show the log popup, hit C-x l to customize "levels", then =s 1 to make the =s (--since) command have level 1 (where levels below some number are shown by default). See https://magit.vc/manual/transient/Enabling-and-Disabling-Suffixes.html for details.
Magit (Emacs) is how I learned git. It's the best version controlling system I have used.
From the linked page:
> It is possible to find the descendents of a check-in in Git using the log, but that is sufficiently difficult that nobody ever actually does it.
Really? I review the logs multiple times a day. In Magit, the binding is simply lb to show logs of all branches.
More.. (but not all) while in the log view:
bc-- Create branch and checkoutbb-- Checkout branchre-- Rebase branchri-- Rebase interactively - squash, rearrange, etcWp- Create patch fileVV- Revert commit
See https://magit.vc for more info.
As i understand it, Magit uses Tramp for accessing a Git repo on a non-local machine. i'm wondering whether what you're experiencing is related to this entry in the Magit FAQ?
Here's the single page manual's section on transiant-display-buffer-action
https://magit.vc/manual/transient.html#Other-Options
If you can't get what you want with just modifying a function to set there, I would look into adding a custom variable and modifying the display logic (dig into transient-init). PR's welcome.
Lastly, I would take a step back and consider how transient keymaps can be optimal. If you need to scroll to find the command because you forget the binding in that prefix, partly because you couldn't see it other times you use it, the usage has drifted out of transient's UI sweet spot.
Transient UI is kind of like modal systems such as evil but also with highly contextual which-key to help you learn and reinforce usage. I would use modal for my most frequent actions and transient for complex things I forget and want to be reminded / guided about.
To make sure that this reinforcement and contextual guidance is happening every time I use the transient, I would make all of them very sparse, easy to scan and remember at a glance. You can use longer key names and group headings too, helping to scan / remember.
If you break the prefix up or make a sub-prefix, your overall tree of commands gets a little more balanced between leaves and branches, and you never ever have to scroll. I think this is the most wise way to lay out prefixes.
Not quite what most consider a GUI but the best git tool out there is Magit for the Emacs generic user-centric text manipulation environment. Magit is a complete text-based user interface to Git. "Magit looks like a prettified version of what you get after running a few Git commands but in Magit every bit of visible information is also actionable to an extent that goes far beyond what any Git GUI provides and it takes care of automatically refreshing this output when it becomes outdated."
>Doom was amazing for the 2 months I used it. I still use it for org-mode which is fantastic. It's really well thought out and has a really great community around it.
Agreed, although I might add :
- Magit : neogit has a long way to go, it'll get there eventually, but not yet. Props to the author for tackling such a huge project though.
- Tramp
>That said, I used to work with a lot of remote machines, and even though I don't now, I still carry this mindset... I try to keep things as "stock" as possible. Just so the habits and muscle memory I develop are as portable as possible. And this is why I use vim.
I respect your opinion but have to disagree on this one. From my experience, I've had a wonderful time using Emacs with Tramp to edit files/projects on remote machines. The experience is seamless with no additional configuration or tweaking needed. All the plugins (company, ivy, etc.) worked out of the box. It's true that there's scp and sshfs but these just don't cut it. SSH is unsteady on unstable connections, which makes these solutions unusable, at least IMO.
I would look into how to modify an existing transient: https://magit.vc/manual/transient/Modifying-Existing-Transients.html#Modifying-Existing-Transients
Once you figure out how to do that programmatically, you can make it part of your configuration for magit.
AFAIK most, if not all, of what you described is possible with Magit with a few keypresses. Explore the dispatchers and the options they provide, e.g. the log and diff dispatchers. Also see https://magit.vc/manual/transient/Usage.html#Usage for more info about how the advanced features of the dispatchers work.
Do you know how to do this with CLI git and you are just asking how to do this with magit from within emacs? Or are you asking in general?
If you are just asking about magit have a look at the documentation .
If you are asking in general, I would suggest starting with a git (and then GitHub) tutorial to understand roughly how git works. Maybe this (didn't really read it) or chapter 2 in the git book or something like that.
Similar to /u/jakkarth, this isn't something I do too often, at least not straight from the CLI. I mostly use magit or straight up ediff executed from emacs for that when I do need to do it. If I'm not on my system (thus no magit, and potentially no emacs) then I'd normally just do a git log and copy the two hashes into scratch buffer of emacs (obviously could be any editor), which is basically the same as your number 1 option.
You could also do:
git checkout <MOST_RECENT_COMMIT_YOU_ARE_COMPARING> git diff <THE_OTHER_COMMIT>
Beyond that, /u/adrianmonk has some good advice. I honestly didn't know about --reverse or -n NUM. The HEAD~# is often very useful. The caveat there is that you'll see articles/blog-posts/etc. that use (here REF is any git accepted reference: commits, HEAD, branch, etc.) REF~NUM and REF^NUM as if they are equivalent . . . but they really aren't. The vast majority of the time (based on my experience, so not necessarily representative of the larger git-using community) they are interchangeable for many things, but the behavior you likely want is what ~ gives you.
I always use bc to create a new branch and check out. I have never done branch spinoff. I read this, but still couldn't quite get the difference between bc and bs. Do you have an example where one would use one vs another? In the example above, I could have used bc too.
I reread that section.. I think this is how bs is different:
bc
- Creates a new branch from anywhere (asks user where to branch from), and checks out the new branch.
- Previous branch remains untouched.
bs
- Creates a new branch from current HEAD, and checks out the new branch.
- If previous branch has an upstream, it would hard reset that branch to upstream (like doing
Xh, but automatically) - If previous branch has no upstream, it would remain untouched (so the entire behavior in this case would be similar to
bc).
- If previous branch has an upstream, it would hard reset that branch to upstream (like doing
I don't recall solving a cherry-pick conflict. Then may be you need to do M-x magit-sequence-continue (or A A) [Ref]. Only then the commit step will complete.. until then you are still in the staging phase.
> Magit is a package for Emacs which can do version control management.
Not quite.
https://magit.vc/manual/magit.html
> Magit is an interface to the version control system Git, implemented as an Emacs package.
Magit doesn't do the VCM. Git does. Magit just pulls the strings of git for you.
If you have that many accumulated changes to make granular commits from, you might find it worthwhile to get familiar with a good Git UI tool before starting (after backing up to multiple locations as others have advised). The Emacs mode Magit could really help with the backlog hundreds of small commits to create. You only need to highlight a section of code and press 's' to stage that section. When you have enough for a granular commit, 'c' to start the commit. For a video demonstration, see Video: An Introduction to the Ultimate Git Interface, Magit!
If you're not an Emacs user, don't let that dissuade you. It is not unusual for new users to start with Emacs solely for Magit or Org Mode, the tools are that good.
That's exactly what I am trying to do, but I have no idea what command should I use, I would guess there is something like "magit-are-there-any-changes-p" or something like that, but I only found somewhere "magit-anything-modified-p", which I am not able to find anywhere in documentation (https://magit.vc/manual/magit.html) for some reason, and it always return t in my case even when there are no modifications.
Pour moi, le seul qui apporte un plus au cli c’est magit, tu peux t’en servir même si emacs n’est pas ton éditeur ou il y a des clones (plus ou moins bien fait) sur certains autres éditeurs.
I will assume you probably already went through the tips here:
https://magit.vc/manual/magit/Performance.html
I’m not sure what is you are running or if the file system is local. I heard running git on Windows is slower but some of the WSL tips can help if that is available to you. Other than that I can’t really provide you much help.
For me using magit under Emacs has massively helped my understanding of how Git works and helped me love it.
I've found oh-my-zsh comes with a ton of aliases for common git commands but learning those requires knowing what they are aliased to (although I like the glod one and use it regularly).
One thing I noticed in the article and I would recommend against is aliasing anything to dd as that just has too much potential for pain, its a very destructive command in its own right if used incorrectly. Yes user accounts shouldn't have those permissions so most will be safe but it definitely not be done under a root account and is probably best avoided.
Try setting --irreversible-delete in magit (does not show contents of removed files in magit-status; see https://magit.vc/manual/magit/Performance.html), then first stage the deleted (old) version of files, before staging the new version. Makes a huge difference when maintaining one's emacs configuration (and packages) in git.
<code>magit</code> in Emacs is a thing of beauty - I literally never go to the shell, except for some reason for my first clone, although it would happily do that for me - habit. Someone must have made an Emacs config / launch script that spins up a magit with vim keybindings...?
As a result of magit, people think of me as a git guru and come to ask me about techniques, or for help to rescue them. It's ironic, because I often have to go to the hidden buffer to see what git commands it's executing. But it doesn't hide git away under any alternate models - you operate on all the same principles, just with single keystrokes and graphical help where it's appropriate (e.g. select a range of commits in the log, and d r for 'diff range' if you like, and see the diffs that occurred in that range).
It does offer a few niceties that amount to multiple git commands in one go, but otherwise it's pretty straight.
This makes me wonder: should I finally donate or patreon to Magit? It is a truly wonderful piece of software I use to get things done at my day job. No code review would be done without it.
Yeah, it's not great and it looks like the Stan people are not very happy with it either.
My guess is that the official way to achieve what you need would be to create your own Transient class similar to transient-option and transient-files. (Note that the docs at Magit's website are out of date compared with Transient's master branch. These look current.)
The easier but more hacky way would be to simply scan the args list you get from Transient for strings starting with data file= or output file= and replace them with two separate list elements.
You're already in emacs, and magit is amazing. In your shoes I'd find the bottleneck and try to make that work. If this isn't enough to make it bearable, look into WSL2.
I don't know of any config "out of the box", but for git support. you can try Magit. To install it simply:
M-x package-install
magit
Check it out! I still use command line for things like merging, pulling, and pushing, but I like magit's log and commit interface: https://magit.vc
Snapshots:
- Magit (Git package for Emacs) contr... - archive.org, archive.today
I am just a simple bot, **not* a moderator of this subreddit* | [bot subreddit](/r/SnapshillBot) | [contact the maintainers](/message/compose?to=\/r\/SnapshillBot)
An der Stelle mal nen shoutout für magit, meine erstes und letztes nicht-Kommandozeilen-Interface für Git. Ich kann mir garnicht mehr vorstellen, git-Befehle einzutippen! Alleine für dieses Tool lohnt es sich schon, emacs mal genauer anzuschauen.
You can try git fsck --lost-found from the root of your git repository. I think Magit cannot help you in this particular case, unless you enabled WIP modes previously: https://magit.vc/manual/magit/Wip-Modes.html.
Another alternative to WIP modes to prevent this kind of situation is using John Wiegley's git monitor: https://hackage.haskell.org/package/git-monitor
> But in git commandline, I can just git checkout release/2020-03-16, and it will create the local branch release/2020-03-16 and set it to track origin/release/2020-03-16. I don't ever need to explicitly create my local branch..
The magit equivalent for this is b l (magit-branch-checkout).
https://magit.vc/manual/magit/Branch-Commands.html#index-b-l
As stated by the project's README, it has taken a lot of work to build Magit, so it probably would take an enormous effort to port it to another language.
I don't know if you use emacs, but magit makes it very easy to stage and commit hunks like this (using git add -p under the hood). You would still have local, unstaged changes though, which sounds like it's not exactly what you want.
> Since I couldn’t get magit working in this scenario
If you don't describe how it's failing, it's hard to help you.
If Magit isn't finding the git executable, then refer to https://magit.vc/manual/magit/Git-Executable.html
Magit usually works fine (albeit more slowly) over Tramp. If it's too slow for you, you're better off (IMO) running Emacs on the remote server, so that Magit is working locally rather than using Tramp.
There are a few things you can do to reduce the risk of this:
Use a version control system, and record small changes. magit really reduces the cost of this practice.
When you run into a blocker like that, once you get past it, don't just race on with your development. Take some time to understand how it happened, and what you could have done to reduce the risk.
Write automated tests to understand how the system is behaving. As you narrow in on the cause of the failure, write correspondingly narrower tests.
Hook your editor up to a linter and type checker, so you get instant feedback on small errors.
Have never felt the need for persistent undo, but wanted to mention magit-wip-mode, which I enable for everything non-trivial. It commits every save to a local wip ref.
Because git is only one vcs. There are a ton out there, and the default command line git interface is only ONE of the interfaces to git. Also, there are a bunch of really good git porcelains beyond the basic ones covered in chapters 1 - 9 of the git book. Magit is a particularly good one built on top of emacs, that is extremely useful even if you don't use emacs for anything besides a more user friendly interface to git.
Asking questions about version control tools is kind of like asking questions about a particular texter editor or IDE. If you can learn a programming language (which has a much larger set of semantics and grammar than any IDE/VCS UI), then you should be able to pick up enough of the vcs UI of any vcs to be a contributor with a quick google search.
Thanks for doing these videos! I just updated the list of Magit (et al.) screencasts yesterday, but I'm happy to do it again. ;-)
The reason that there is no specialized "merge pull-request" command is that no such command is necessary. Ah... I just realized that you never actually checked out the pull-request locally.
Well the way forge works, is centered around the idea that you do that. You can of course review a pull-request on Github/Gitlab, but that is only really appropriate for the most trivial changes. (Despite what they might try to make you believe to do a proper review you need to use a decent text editor with decent git integration....)
So the typical workflow is this:
- Check out the pull-request using
b y. That goes beyond just creating a local branch. It also creates a remote if necessary, configures upstream and push-target, etc. - Review, possibly making changes.
- If you made changes, then push them. This works even if the feature branch lives on someone else's fork. (Unless they did not bother with a feature branch and ask you to merge their master. See https://github.com/magit/magit/wiki/Dedicated-pull-request-branches for more information about why you should not do that.)
- Merge locally and then push to the "pull-request". Almost always that means merging into "master" and then pushing to "origin/master". A good way of doing that is to use the "merge into" command on
m i, that automatically suggests the appropriate branch.
When you merge a branch corresponding to a pull-request, then Magit automatically cleans up after you (asking some questions for safety reasons). So normally after you have merged (or deleted) a pull-request branch, the branch and its remote are removed and everything is nice and tidy.
See https://magit.vc/manual/magit/Resolving-Conflicts.html magit is using ediff. magit is using ediff.
So the second technique to speed up ediff is still useful.
The first technique I introduced is for `git mergetool` optimization, it can't be used if you use magit.
When I went back to editing in Emacs (using Spacemacs), I rediscovered Magit, which works from inside Emacs. It works via SSH logins as well.
My Emacs draws slow over RDP on Windows, so I'm using Visual Studio Code with GitLens, Git Graph, and tinkering with a few other plugins.
We use git-flow at work, but it is simple enough that we don't need a special layer for it.
Incorporating version control works as it usually does:
- Put your Org files under version control. For example with git:
git init .; git add .; git commit -m'initial commit' - Start working on your files.
- Every now and then, do a commit:
git commit -am'your message' - If you have a conflict, use regular conflict resolution strategies like your editor. I presume you're using Emacs which has great Git integration through Magit[1].
organice is a Progressive Web Application[2], it is not a native application. Hence, you don't need to install it or go through an App Store to install it. On the other hand, it's not a native application and does not provide widgets on Android.
Magit supports some WIP modes where it will automatically create WIP refs just before a potentially destructive action in a repository. To enable them: https://magit.vc/manual/magit/Wip-Modes.html
Emacs Lisp is tetris-complete, so you can do anything in Emacs you could do in other editor - but it might take you to write that functionality :)
With this said, there is a way of doing that without being a programmer:
(1) Get Projectile - this package allows to navigate projects (Spacemacs should have it by default).
(2) Read the docs! Quick find over their "Usage" page shows that projectile has capability to:
- Run a standard test command for your type of project.
- Display a list of all test files(specs, features, etc) in the project.
- Toggle between an implementation file and its test file.
etc. - I don't remember the usage off top of my head, but this should be all you need. It works with the help of git - be sure to work in the repo. To help you work with the repo, I recommend Magit - although that should be included with spacemacs as well :)
> Emacs also has Magit, the best Git graphical interface out there.
A trifle nitpicky, but looking at the home have: https://magit.vc/ I'd have serious doubts about calling the magit interface "Graphical"...
> Emacs also has Magit, the best Git graphical interface out there.
A trifle nitpicky, but looking at the home have: https://magit.vc/ I'd have serious doubts about calling the magit interface "Graphical"...
> Emacs also has Magit, the best Git graphical interface out there.
A trifle nitpicky, but looking at the home have: https://magit.vc/ I'd have serious doubts about calling the magit interface "Graphical"...
> Emacs also has Magit, the best Git graphical interface out there.
A trifle nitpicky, but looking at the home have: https://magit.vc/ I'd have serious doubts about calling the magit interface "Graphical"...
You can change your default settings so it pulls from a different remote. Here's a snippet from https://magit.vc/manual/forge/Token-Creation.html#Token-Creation
>If only one remote exists, then Forge uses that unconditionally. If several remotes exist, then a remote may be selected based on its name.
>
>The convention is to name the upstream remote origin
. If you follow this convention, then you have to do nothing else and the remote by that name is automatically used, provided it exists and regardless of whether other remotes exist. If it does not exist, then no other remotes are tried.
>
>If you do not follow the naming convention, then you have to inform Forge about that by setting the Git variable forge.remote
to the name that you instead use for upstream remotes. If this variable is set, then Forge uses the remote by that name, if it exists, the same way it may have used origin
if the the variable were undefined. I.e. it does not fall through to try origin
if no remote by your chosen name exists.
GUI tools are not necessary for using git, but they can make certain operations quicker/easier to carry out. On the other hand, GUI tools often expose just a tiny subset of the functionality of the CLI.
For me, the the probably most important "GUI" support is for staging individual, partial, changes for a commit. On the command line, you'd use git add -p, but that's tedious. Staging (partial) hunks comes up often when realizing you want your changes to be split up into multiple commits, or wanting to split up a commit after the fact.
I happen to use <code>magit</code>, which allows to to select parts of changes "graphically" (although completely keyboard-based), and stage them with a single key stroke. It also makes branching, merging, and rebasing more convenient -- for example, to change a single commit in the ancestry of the current branch, I can type r m on that commit, and when done with the changes, I can press r r, and done! Using the CLI, this would be an interactive rebase (git rebase -i), editing the rebase action list appropriately, making the changes, and git rebase --continue.
Well for example there's magit which is neither commandline nor GUI (although I guess this depends on what you mean by GUI). Also the magit homepage uses this terminology.
But regardless, what I'm asking about is a UI.
In the command line, git add -i does that.
However, there is an Emacs software which is called Magit, and it is the perfect solution for that kind of workflow. You can edit files in Emacs (which is very efficient), but you can also use it only as a git GUI.
Not directly an answer to your question as written, but it's useful to know that the author of Magit has published a companion package called forge which includes support for self-hosted GitLab installs. I don't currently use it to open Git*Lab* PRs, but it is nicely integrated in Magit due to the shared author.
It's included in the github layer if you're a Spacemacs user, and I enable it like so:
(when (configuration-layer/layer-usedp 'github) (with-eval-after-load 'forge-core (add-to-list 'forge-alist '("my.hostname" "my.hostname/api/v4" "my.hostname" forge-gitlab-repository))))
If all you need to do is make it simple to run "git town sync", you might be able to get away with some of the built-in functions for running git manually.
​
For instance perhaps something like this:
(defun my/magit-town-sync () (interactive) (magit-shell-command-topdir "git town sync"))
(use-package magit :ensure t :pin melpa :bind (("C-c g s" . magit-status) ("C-c g y" . my/magit-sync)))
I'm fairly certain that this isn't going to do everything you want; but it might at least give you a quick hack that lets you keep moving forward while you work on the full solution
Awesome! Looking to replace hydra with this. Is there a way to hide certain keybinds/key hint but still have them be accessible through the transient map?
​
Looked like it could maybe be done with :hide keyword but I haven't gotten it to work properly!
​
https://magit.vc/manual/transient/Group-Specifications.html#Group-Specifications
I don't use magit. The builtin vc is good enough for me. That said ... https://magit.vc/manual/transient/Introduction.html claims
> Info manuals do not support images ...
Has someone looked at https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Images?
Here's your code copied from "View source" and spread across multiple lines so that we can actually read it:
(autoload 'org-read-date "org")
(defun magit-org-read-date (prompt &optional _default)
(org-read-date 'with-time nil nil prompt))
(magit-define-popup-option 'magit-log-popup
?s "Since date" "--since=" #'magit-org-read-date)
(magit-define-popup-option 'magit-log-popup
?u "Until date" "--until=" #'magit-org-read-date)
This would be equivalent:
(transient-insert-suffix 'magit-log "-A"
'("=s" "Limit to commits since" "--since=" transient-read-date))
(transient-insert-suffix 'magit-log "=u"
'("=U" "Limit to commits since" "--since=" transient-read-date))
But that is not actually necessary because I have added all (or nearly all?) of the suggestions from https://github.com/magit/magit/wiki/Additional-proposed-infix-arguments-and-suffix-commands.
So you just have to enable this suffixes, as described at https://magit.vc/manual/transient/Enabling-and-Disabling-Suffixes.html.
Looking good. If you use Magit, you may find the work in progress modes, in particular magit-wip-after-save-mode to be a good fit for handling backups as well.
That shows the tree but where are the commits? Can I zoom? Why is it oblique? Can I get the state of the file at a specific commit?
I just checked out both VS Code and Atom. Apart from doing simple things they wont even let you see things. There are plugins for some of the trivial things like git-log but I didn't found them even close to what Magit offers me. I can literally switch to any version of the file, see any kind of diff, apply any commit, merge in my own way, rebase, stash, run git commands and lots more.
Quoting from their site:
> While many fine Git clients exist, only Magit and Git itself deserve to be called porcelains
I don't understand the whole controversy, is this really so difficult?
https://magit.vc/manual/magit/Installing-from-an-Elpa-Archive.html#Installing-from-an-Elpa-Archive
It's evaling one snippet of elisp and two commands. Might as well be just one elisp expression that you can paste into scratch and C-x C-e.
It's the same effort to install it then as it would be if it were in ELPA.
Magit is the Emacs package for git, and is the best git client I've ever used. Even in those rare occasions when I code using something else than Emacs, I use Emacs to do git related tasks.
In my opinion this package alone is worth the effort to learn Emacs.
> I have yet to see an IDE which provides the level of git support that makes an open terminal obsolete.
If you count Emacs as an IDE, magit is the most complete and intuitive git UI that I've ever used. If you're using a different IDE, maybe keep Emacs + magit open in that terminal window. :)
I'm still using magit-90150116 , yes, the very old version, this is the issue page when I upgraded it to v2.1.0 on Jul 20, 2015 and I talked about the performance there, today (Jan, 8, 2017) I remove old magit and related packages and then upgrade magit to latest v2.10, clean all my old magit configuration in init.el and then make new simple configuration suggested at https://magit.vc/manual/magit/Performance.html#Performance ,
and test the performance just as I did in the issue page using M-x magit-status to load the magit-.emacs.d buffer and no more action, and it takes around 30s, yes, 30s.
And then I restore all my old magit-and-related packages and my old configuration, try the same action to load into the magit buffer for my .emacs.d, same repo, nothing changes, it takes less then 1s.
Actually I did this several times when new versions of magit keeps coming out, and they were basically all the same result.
I guess I'll stick with the old magit forever.
Interactive rebase is pretty much the best thing. I use magit for emacs which makes this a few keypresses and has an always-visible list of available keys and commands for reference. Self-documentation is nifty.
put cursor on a commit in the status buffer/a log buffer/etc (or anywhere else to see a list of commits to rebase from)
r ito rungit rebase --interactive(r -A ifor--autostash, I use that a lot)move cursor around the rebase buffer,
RETto show a commit in a separate window,C-kto kill a commit,M-n/M-pto move a commit down or up in the list,etoedit,sto squash,ffor fixup, etc.C-c C-cto start the rebase operationif a conflict or nonzero exit status from an
execcommand during the rebase occurs, fix it andr rto continue, orr ato rungit rebase --abort
It's great because there's an almost-100% mapping between switches/options and commandline flags and arguments, and $ on any magit buffer will jump to a log of the git commands it's running in the background, so it's easy to follow what it's doing.
Not only that, but if I run git rebase --interactive from my shell, I get an interactive rebase buffer with the exact same semantics as if I'd used magit to start the rebase.