Is "forge" a well known term in this context? What does it mean exactly? A web based git host that adds collaboration features like issues and pull requests? Seems like that from the context but I've not seen the term before.
Isn't that the beauty of language? Communicate meaning through words. I agree that the word "forge" might not be defined as "a source host that adds collaboration features like issues and pull requests", however you have to admit that the word captures that meaning fairly well. What other word could be used to communicate the same meaning? Hub? Bucket? Lab? Hut? It could very well be a nod to SourceForge, but the idea of a software forge captures well, in my opinion, the kind of services that those websites offer.
Furthermore the "definition" they provide is something they came up with; a Google search for portions of the definition only returns results for the article itself.
Then your Google isn't my Google. If the definition is used on sr.ht[0], then it's pretty much galvanized. Not to mention that I've heard it used that very way over the decades that I've been in software development.
That's so true! Emacs has got some modern and really well crafted packages during last decade (e.g. Magit, Org or Notmuch). It's a really interesting and vibrant platform right now. I have high hopes for lsp-mode.
Another package with great UI is calfw.
Of course, there were already plenty of great classic packages (e.g. Dired, Calc, Gnus or Eshell) and modes (e.g. AucTeX, SLIME, ESS...). But things are getting really good lately.
ELPA and use-package have also done away with lots of friction points when installing and updating packages.
Emacs seems to be probably the only one piece of software still in use that can be considered a software runtime for text-oriented applications and UIs. It gives building blocks that strongly favor function and efficiency over form (though one grows to like the minimal, text-based aesthetics). If you write your code correctly, you can get some pretty awesome features for free - like TRAMP, i.e. access to remote files as if they were local, across a variety of protocols and with ability to tunnel through networks.
But my absolute favorite right now is that, unless you purposefully screw it up, your Elisp program will look and work the same way on GUI Emacs frames as it will work on Terminal frames. That is, I get to use it from anywhere, by SSH-ing to my computer and running `emacsclient -t`. A capability I use extensively for programming on the go, and which alone gave my small laptop years of extra useful life.
I love Magit, and I'm excited for more software that's built on Emacs.
I'm very interested in this. I hadn't seen magit-popup, but I'll check it out, and also Transient when it comes out. If you want anyone to help look over the manual, I'd love to help (email in profile).
Thanks, I probably just need to start forcing myself to use it for a while and try and get over the initial hump of just wanting to get things done quickly using the tools I already know.
It depends almost completely on git for tracking repository state, at least for basic usage, so you can switch back and forth to your familiar methods quite safely. That way, you only have to learn a little of it at a time.
And at any time, you can just use "! !" to run an arbitrary git command on your repo, if you so choose. Since Magit depends on git for status tracking, you don't risk breaking anything.
I have been using it happily, but I have an issue where I have a fork on github, but I can't get the forge to point at upstream instead of my fork, it changes to the other github as soon as I set pus Default if I remember correctly. Is there any way to do this?
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.
This is from the manual, but I will have to move (or copy) to a more prominent place within the manual. (This is currently in the node titled "Token Creation".)
