@b0rk I noticed while setting up my new machine that #debian has a git-hub package that purports to add a command line interface. #git was always meant to have "porcelains" above it that used the underlying primitives to push and pull branches. I guess that's the layer you'd want to integrate stuff like that. #magit can be extended to access forge details and do code review.
@b0rk@petes_bread_eqn_xls I don't worry too much with #git, usually it allows you to recover from mistakes. There's always reflog, cherrypick, rebase and friends to move commits around. So I think the "I need to be careful" mindset is counterproductive, though I understand it when you are not confident with the above tools. Of course upstream main should be protected, don't want to be messing with that.
Btw, #magit for #Emacs has a "spin-off" command which creates a new branch from the current branch and resets the current branch to upstream. Found that super useful when I made a few commits on main, forgetting to create a feature branch. Could have solved this otherwise but a dedicated command saved some time. I think git doesn't optimize its CLI for UX because it expects third parties to build better porcelains for it.
#github#copilot is SO GOOD. I'm constantly blown away by how much of a time saver it is having copilot working.
I'm also super amazed at how good it is at writing code in #unisonlang since it is a language with very little software written in it to begin with, coupled with the fact that practically NONE of it is ever checked into github, so there is likely very little #unisonlang code in the training set
I had been using emacs pretty much daily from 1991 to 2022. In 2020 if you had asked me if I would ever move away from emacs I would have said "probably never".
However today I find that I pretty much spend all my time in #vscode because I want both copilot and #LSP always working, and that's non-trivial in emacs these days
The one thing I will do with #emacs consistently these days is use #magit for any non-trivial git operations. I've never seen a #git client that rivals magit.
Here's a function using #magit to show the diff of the current buffer since a certain date/time.
My use-case: I put my work notes in a single org file. When our daily standup starts I can quickly review what I worked on / wrote down in the last 24 hours.
I've seen a lot of pro-#Fossil, anti-#Git discussion recently.
Not that I love Git, but it does the job and almost all deployment platforms have support for Git only.
And, am I the only one who needs a staging area because I have to commit only a part of my changes? Often even line-based.
And, sometimes I want to squash 20 ugly commits into a single one, destructively changing the commit history. Really!
And, sometimes I need a hosting platform for a project and there is not a single serious one for Fossil. What's the point in using Fossil when I have to do a Git-export?
And, most importantly, there is #Magit :blobcatmeltlove:.
So ... although I can feel the love for Fossil, it simply doesn't work for most of my use cases.
I am so proud of myself 🙂: I have just used #git#CherryPick for the first time ever and, drum roll, it worked! Did it via the command line as for some reason I get lost sometimes using #magit in #Emacs even though magit is fantastic for the usual activities.
I consider this to be obvious, but the correct way to design (laptop/desktop) UIs for most applications is a slick, snappy graphical UI with completely keyboard-based and discoverable navigation.
Interestingly I know no application which does this, although it is certainly doable.
Note that Emacs is far more than a large window with monospace text. GUI Emacs (the preferred way to use it) supports variably sized fonts (both horizontal and vertical) images and more.
Emacs users prefer text-based interactions as they're easy to navigate with a keyboard but even text-based UIs can do quite a bit more than you might expect.
Check out (heh) #Magit for example.
Whether Emacs' UI is "slick" is subjective but it's certainly more than a monospaced grid of characters.
#Lazygit is five years old. I’ve been using it for a few years, and it’s made interacting with #Git so much more convenient. I used #vimagit (inspired by a coworker’s use of #Magit) before it, and the official Git #CLI before that.
@masukomi I alternate between magit-blame and vc-annotate. They seem to have orthogonal functionality. My ability to do CLI git is abysmal -- I can't remember any of the options or their correct order. #magit makes that a non-problem. The ability to line-by-line commits within hunks in magit is very useful. I have no idea how one would do that efficiently on the command line.
Hey everyone!!! I just released a really important usability update for #Gex, which is my #Rust#OSS project for #git interaction inspired by #Magit
Finally, we have scrolling! This is a feature that should've been added a long time ago, but here it is. Spent a long time tweaking it to try and get it to feel "right" so I'd love to know what you think!
My third #emacs package is on #MELPA! Use heroku.el to as easily manage your #heroku instances, as you manage git with #magit. Transient is the most efficient interface possible! You can tail logs, run commands like bash and python, restart and promote dynos, connect to Heroku Postgres with #psql using built-in Emacs sql functionalityand more!
I feel like remote editing will always just, no matter what
SSH terminal editor: gets weird on a shared server, can be annoying with some latency
editors that boot up a daemon: the daemon, often somehow really slow and clunky
SSHFS: you don't have the entire environment
anything like remote desktop: why :haggard:
I'm using #TRAMP for "everything". IMHO, it works, but it also has its issues. Esp. it can be horribly slow sometimes, and its interactions with other packages are strange for me, i.e. #magit.
I'm almost out of #emacs packages that are plug-and-play. So today I'm rehashing an old twitter thread about #Magit, THE porcelain for #git.
First, let me talk about my impression of git pre and post magit:
Pre-Magit, I wasn't happy/good at using git.
Post-Magit, I believe all git commands are clunky & unwieldy (especially in comparison to Magit).
The closest that my friends have come to making git better is with copious autocomplete setups (I think it was tmux, fzf, and a few other things). But I still say that magit is probably the lower bound on how nice it can be.
Eg: stage+commit in a wip branch, switch to main, pull from remote, merge wip to main, push to remote is:
S, c c, b b ⏎, F p, b b ⏎, m m ⏎, P p.
Done, in just 16 key strokes. At most there will be a couple of keystrokes extra before each enter if there are multiple branches to select from (but that would be true of any tool).
Not only do the keystrokes feel like the lower bound, the default choices are extremely sane.
Finally, it is not just the minimal keystrokes, it is also the extent of information that magit exposes and the amount of control it provides. Until I started using magit, I didn't know that beyond the usual amend to an earlier commit, you could also expand it (add changes, same msg) and reword it (change msg, no changes). Further, magit also exposes fixup and squash right in the commit submenu (see screenshot). In git, I would have no way of knowing what to do.
Magit is the git porcelain that makes using git feel like doing magic.
I'm writing a large document in #latex in #emacs and I track my changes with #magit. Is there a way to view to view Levensthein edit distance or similar instead of line diffs? MS Visual Studio actually does this quiet wonderfully despite being otherwise less than wonderful.