Hacker News new | comments | ask | show | jobs | submit login
Forge – Work with Git forges from the comfort of Magit (github.com)
141 points by jdormit 7 days ago | hide | past | web | favorite | 34 comments





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.

Probably a reference to the granddaddy of these kind of sites, Source Forge.


This article has no citations for the history/use of the term. It was largely written by a single editor over a decade ago.

> over a decade ago

If it ain't broke, don't fix it. Also: https://www.computerweekly.com/blog/Open-Source-Insider/What...


That's exactly the kind of article that gets written from a page on Wikipedia.

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.

[0] https://meta.sr.ht


https://news.ycombinator.com/item?id=18458908 people are using the term 3 months ago

I know this is off-topic, but: a resource I really wish existed is "how to build Emacs UI like Magit".

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.


Thanks for the calfw recommendation! I just installed it and it's really nice.

> I have high hopes for lsp-mode.

I do too, but I've had no luck at all with it so far.


Not that much off a topic, and a great question.

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.


You might have a look on https://github.com/magit/magit-popup

I am hoping to release Magit-Popup's successor Transient tomorrow (or later this week if I can't get the manual done in time).

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).

In the same vein it would be nice to have the same for "how to build an emacs UI like sx.el for your favorite discussion site".

Oh wow, I didn't know about sx.el either, and I just tried it and ... I'm for sure going to be spending a lot of time in there.

Do you use Emacs besides Magit, and is the Emacs integration essential to what you want? What other tools or workflows would you want to build?

How would we even communicate with a creature so alien they use Emacs just for Magit?

Try using Org Mode as a common plane for communication.

I hear good things about magit, does anyone have any good learning resources for someone who is relatively new to emacs?

Here's a recent talk/screencast by John Wiegley that covers a lot of Magit tips and tricks: https://www.youtube.com/watch?v=j-k-lkilbEs

Thank you for this!

It doesn't really get any better than the documentation on the homepage:

https://magit.vc/


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.

try this one as well https://youtu.be/1IYsiHXR620

Mike Zamansky has a whole range of emacs related youtube videos.


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".)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: