@tarsius Man, reading emacs-devel, it always amazes how some people seem to want to resist using Magit, preferring even shell commands. They're like, "Err, give me some examples of REALLY COMPLICATED git things and how Magit would make THOSE easier. Don't tell me about how Magit makes simple things fast and complicated things simple."
Magit makes me feel like a git ninja, like Magit is a musical instrument that I can press a few keys to express what would take paragraphs to say. I feel sad when I see people who won't even try it; they're missing out on so much.
I understand the slowness comes from Emacs having to render thousands of lines even if they're not visible.
So, I wonder if there's an easy way of leaving only the conflicts in the buffer (removing all the lines of other changes)
5 replies
Hi there, I am having issues while connecting through SSH on a remote with an outdated git by default, but with a working git in another folder. Setting up magit-remote-git-executable manually to point at the working git binary seems to work; unfortunately, this makes it nontransferable to other devices. In any other case, it just recognises the default git (which is 1.8), causing a Magit requires Git >= 2.2.0 error.
We've tried a couple of things here: https://emacs.stackexchange.com/questions/67975/load-right-version-of-git-while-connecting-to-remote but they do not work (not sure if it's because my elisp is terrible or they actually do not work). Would you have any idea on how to fix this on either ends?
("/software/git-2.18.0/bin/" "/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin" "/local/bin" "/local/freeware/bin" "/local/gnu/bin" "/usr/freeware/bin" "/usr/pkg/bin" "/usr/contrib/bin" "/opt/bin" "/opt/sbin" "/opt/local/bin") but unfortunately it still favours the system git installation while looking for it
I'm sometimes missing a "drop commit", i.e. a commit I make and keep for a while, but as as soon as I do git rebase --autosquash ... it would be removed. Typically I do it for extra logging that I want only temporarily while I experiment with things.
Maybe I'm completely alone in wanting this though...
6 replies
Does anyone know if it's possible to format commit message in a way that it would have "collapsible" groups while reviewing it in magit-revision-mode?
We have a convention to put the list of squashed commits at the end of the commit message on "squash and merge", sometimes those commit messages tend to grow big - we not only include the message, but also keep the QA instructions and other relevant information in the message.
ghub because that is more low-level. It makes it more convenient to make requests, handling tha authentication stuff and such; it does not implement concrete requests. github-tags could use ghub to benefit from its convenience features though.
github-tags also sets global variables (not per-repository variables) to store individual parts of the returned data. That may work well for the authors use-case, but since it isn't documented at all others probably won't use it.
1 reply
magit-insert-revision-message and use it in magit-revision-sections-hook.
