Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Magit, the magical Git interface (2017)

emacsair.me

Post reply on HN
Print view View original

221–230 of 357 posts

Re: Magit, the magical Git interface (2017)

#221

Post by PaulDavisThe1st »

rich_sasha wrote: post #195
theli0nheart wrote: post #178

Earlier quoted context omitted.

That's by design; Git history is intended to be immutable when working with others. But, if you haven't pushed something up to a remote, the right command to make more changes is to use `git commit --amend`.

> Git history is intended to be immutable when working with others. That's another pet peeve (though maybe less git's fault): immutable, yes, but then rebase is pushed quite liberally. Arguably not by git itself, but by many online learning resources. It's convenient, and mostly works, but then occasionally really stings you. ...yet undoing the last commit, arguably the least aggressive of history-rewriting commands,…

How is "git reset HEAD~" "awkward"? It's not obviously named, but as was noted above, if there was git-uncommit, it would need every option that git-reset has, and so it would just be an alias, without the final argument.

"History is immutable" is generally accepted as describing the contents of commits, not their id's or relative ordering.

Re: Magit, the magical Git interface (2017)

#222

Post by PaulDavisThe1st »

GlennS wrote: post #144
kmarc wrote: post #135

Earlier quoted context omitted.

I am the same. After the pandemic started and I had to witness over screen share how colleagues "use" (fight) git with all sorts of GUI tools, I had to realize that no GUI can be good enough while one doesn't understand git, or, even worse, it can be contraproductive, because people using these GUIs _think_ they understand, but they don't. I even ended up creating a (tailored) 2x90min git course... All that said, I h…

Why would I use magit over the git CLI? 1. Discoverability. It'll display the contextually relevant options and commands at most points. By using magit, you're learning the git CLI commands at the same time, including commands that you'd normally never come across without a comprehensive read of the manual or release notes. 2. Fewer keypresses. Also, extra shortcuts for some common operations. 3. The bits that CLIs a…

Re: 3 ... I find that the CLI ("git add -p") works here when the scale of the changes I've already carried out is fairly small and there are not too many orthogonal changes in the file tree that I want/need to commit separately. If that happens, it's off to magit I go.

Re: Magit, the magical Git interface (2017)

#223

Post by foobarbaz33 »

jolmg wrote: post #112
grumpyprole wrote: post #91

Earlier quoted context omitted.

I'm pretty sure it's the main reason. Look how many times Magit shells out to git to render the status buffer, too many to count: https://github.com/magit/magit/issues/1327 In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.

I just called the status buffer from magit on a repo. It was 23 calls to git, mostly for rev-parse. The status buffer appeared instantaneously on a decade-old laptop. Whatever is causing the slowness you're seeing, I don't think it's just because of the number of calls. It's probably the slowness of one or two specific commands, perhaps due to repo size.

Try opening the status buffer on a project with 50+ submodules. On microsoft Windows. Prepare to wait over 1 minute.

Re: Magit, the magical Git interface (2017)

#224

Post by PaulDavisThe1st »

amake wrote: post #203
NateEag wrote: post #198

Earlier quoted context omitted.

Magit has great support for staging parts of lines - select the section you want to stage and press 's'.

> Magit has great support for staging parts of lines This is news to me. > select the section you want to stage and press 's'. It stages line-wise for me. How do I get it to stage less than an entire line?

The second line you quoted tells you how.

Re: Magit, the magical Git interface (2017)

#225

Post by rich_sasha »

matheusmoreira wrote: post #215
rich_sasha wrote: post #139

Earlier quoted context omitted.

What I dislike with git terminal UI is that commands reflect the innards of git, not what the user wants to do. It also forces a deeper understanding of the innards for basic commands than ought to be necessary. Examples where undoing an operation looks totally different to doing it: - To stage a change you `add` it, to unstage you `reset HEAD` - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The l…

Yeah, git is certainly a low level tool. That's actually what I like most about it. There's a few fundamental concepts I get to manipulate directly with git commands. I like dealing with innards like this because I can form a mental model of the tool. High level tools are a lot harder to understand. I think the problem with add, commit and reset is they aren't low level enough . The reset command in particular is jug…

I probably pushed and pulled O(100) remote branches over the past decade (jeepers I'm getting old), so roughly once a month. It's not that rare, yet I still haven't memorised them, because I find them so unintuitive.

Re: Magit, the magical Git interface (2017)

#226

Post by matheusmoreira »

rich_sasha wrote: post #159
leephillips wrote: post #152

Earlier quoted context omitted.

“ - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The last example is also where you get pointed to an unsafe command” Who pointed you there? If I want to undo my last commit, meaning the commit itself, not the changes to my file tree, shouldn’t I say `reset --soft`?

My bad, misgoogled. But this in fact reinforces my overall point. I don't want to be messing with `reset`, hard or soft. What is `reset`? [I now know because I had to learn, but I'd really rather not]. What I want is `uncommit`, or something like that.

What is "uncommit" though? Do you want your changes gone, staged or unstaged?

Re: Magit, the magical Git interface (2017)

#227

Post by tacker2000 »

I never used Magit, I have been using SmartGit for years now and I see the great benefits of git GUIs.

Checking logs, checking and merging changes, searching for files and commits… all this is much easier to do with a GUI. Of course, for complicated stuff one should still know the cli commands, but 99% of the time the GUI is what makes me more efficient and faster.

Re: Magit, the magical Git interface (2017)

#228

Post by avgcorrection »

skohan wrote: post #65
KingMob wrote: post #40

This post is the epitome of "tell, don't show", when it should be the opposite. It reads like it wants to convince you to try magit, without demoing a single example of how it's superior.

> Commands are invoked, not by typing them out, but by pressing short mnemonic key sequences. It also sounds magical in the worst kind of way.

In the same way that abbreviations are magical relative to spelled-out words.

Re: Magit, the magical Git interface (2017)

#229

Post by ziml77 »

shagie wrote: post #167
ziml77 wrote: post #106

Earlier quoted context omitted.

Really? I tried it yesterday from within Rider and I gave up on it because I couldn't even figure out how to push or pull. Best I could find was fetch. Not the biggest deal since neither of those commands require interacting with the output which makes them equally easy to run from the terminal, but it's strange that they're not available in an immediately obvious place.

You can customize the menu (and I do) to add a Git menu sub panel (for lack of a better word) that has an up and down arrow for push and pull. In the lower right, there's the vcs "where you're at" that shows the current branch. From there you can see the status of your branch compared to others (if you need to fetch them), or you can update branches (even those you're not currently on) along with branch specific oper…

Oh wow I didn't know that search everything in Jetbrains products included the menus and not just the contents of the project. That's handy to know. I've been a fan of Ctrl-Shift-P in Sublime Text, so it's always good to see similar features in other software.

Re: Magit, the magical Git interface (2017)

#230

Post by hbn »

brabel wrote: post #69
bsdubernerd wrote: post #56

For the sake of discussion, can we get some contrarian views? I'm using magit, along with tig, plain git and sometimes (!) even plain "vc", depending on context. I'm in the camp that thinks it's ok and it's pretty comfortable to use within emacs, but I don't see the earth shattering praise I see every time it's mentioned here. Tig for example is so much faster for history and blame perusal that I find it faster to ke…

Ok, let me try. I prefer IntelliJ's git interface. Magit can do everything IJ can, but in IJ, I can find how to do things more easily and it just feels easier to do things, probably because it's much more GUI than text compared to Magit. For example, difficult merges are extremely easy in IntelliJ, I can edit code in the diff view itself while I resolve conflicts... in Magit it requires getting used to the different…

IntelliJ's git interface is basically the only way I can use git, or at the very least pull off anything other than the most standard tasks.

Its UI for resolving merge conflicts is so intuitive and powerful. You get 3 panels: local changes on the left, remote changes on the right, and merged in the middle. It's got colored highlighting going across from each of the side to the middle, showing where the changes want to go to, and you click arrows to accept/dismiss left or right, and sometimes it'll even have a suggestion for a way to take both of the changes (indicated by a magic wand). And you can also just type into the center editor if you want to not use either side, and manually rewrite the resolved change yourself, whether that be copy-pasting from each side or whatever you want to do.

It's saved me so many times, it's practically worth the cost of the entire IDE on its own.

Post reply on HN