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

251–260 of 357 posts

Re: Magit, the magical Git interface (2017)

#251

Post by IshKebab »

piaste wrote: post #173
IshKebab wrote: post #125

Earlier quoted context omitted.

I disagree. It's ok. But it doesn't even have a DAG viewer. What kind of GUI doesn't even have `git log --tree`? Hopefully that's just because VSCode didn't allow arbitrary widgets until recently. Presumably they're working on it.

Git Graph [0] already exists as a different extension from GitLens. It works quite well, although of course it would be nice if the two extensions could integrate with each other. [0] https://marketplace.visualstudio.com/items?itemName=mhutchie...

That looks nice! Yeah these things are so integral to development it would be nice if they were just core features of VSCode.

Re: Magit, the magical Git interface (2017)

#252

Post by [deleted] »

dan-robertson wrote: post #114
jolmg wrote: post #95

Earlier quoted context omitted.

> but rather around being selective about crafting self-consistent but single-theme revisions Actually, I think git's got Magit beat on that. Magit might make it easier to stage specific lines, but git can stage specific parts of lines or even changes that are completely different than what's on the worktree, through the editing of diffs with `git add -p`'s `e` option.

What percentage of git users do this compared to the percentage of magit users staging line-by-line or confidently amending/cherry-picking/interactive-rebasing?

[deleted]

Re: Magit, the magical Git interface (2017)

#253

Post by weaksauce »

wodenokoto wrote: post #58
jwr wrote: post #43

Magit is such an unbelievably good piece of software. If you haven't used it, please at least take a look. It seems like "just a GUI for git", but that's missing the point — many operations suddenly become frictionless, so your entire workflow changes. I regularly do things like "stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one,…

Can I like magit if I don’t like emacs?

if you like vim i'd suggest you install spacemacs and the git layer.

Re: Magit, the magical Git interface (2017)

#254

Post by yissp »

matheusmoreira wrote: post #137
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…

I gained a better understanding of git through this document: https://eagain.net/articles/git-for-computer-scientists/ I'm not a computer scientist and I think it's understandable. Everything became a lot more clear in my mind once I understood the inner workings.

The underlying model of git is not too hard to understand, and is actually pretty elegant. There are a number of good explanations online, including the one you linked.

The git tool itself, though, often operates at a much higher level of abstraction. I think that's more where the reputation of being hard to learn comes from. For instance, you'd probably need to write a paragraph or two to explain what "git checkout " does in terms of the actual object store. Add to that that the CLI is poorly designed - many commands have misleading names, a given command will do completely different things depending on the flags, there's a lot of implicit / counterintuitive behavior, and so on. See https://stevelosh.com/blog/2013/04/git-koans/ for some funny examples.

Re: Magit, the magical Git interface (2017)

#255

Post by rich_sasha »

folex wrote: post #234
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…

> If you mistype it and nuke more than the last commit, that's also a bit bad - and fairly easily done. If you ever run into this, you can use `git reflog` to see the history of your local actions. It's possible to revert almost any action with it. Reset a few commits that you've never pushed to remote? No worries! Just go to `git reflog`, find a point before it happened, and `git reset` to it. $ git reset --hard HEA…

Yes, except... again, this is fighting fire with fire.

If you don’t know git internals, mistype a non-obvious command and lose a bunch of commits, then “look in the reflog” advice is frankly adding insult to injury.

Re: Magit, the magical Git interface (2017)

#256

Post by IshKebab »

JamesSwift wrote: post #160
IshKebab wrote: post #123

Earlier quoted context omitted.

Does anyone actually do line-by-line staging using the CLI? That sounds masochistic. Most editors/GUIs make it very easy.

I always use `-p`. Its my default so its not 'more work'. Its the best way to get clean, atomic, history. It also lets me do things like mock out services or hardcode connection strings without having them accidentally exposed. I've had way too many accidental commits in the past to go back to full file add. EDIT: also, it isnt 'line-by-line'. Its logical-chunk-by-logical-chunk. The algorithm will try to group local…

I wasn't really asking how many people do line-by-line commits in general. Obviously it's useful for all the reasons you said. But it's particularly masochistic to do it via the CLI rather than through a GUI or editor.

The hunk algorithm is not very good in my experience and following the prompts to split them is just about as nice an experience as editing files with `ed`.

Have you tried using a GUI or an editor that supports staging selected lines?

Re: Magit, the magical Git interface (2017)

#257

Post by rgrmrts »

dhess wrote: post #68
jolmg wrote: post #64

Earlier quoted context omitted.

Is the launching of processes on Windows so much slower than on Unix-type OSes that it would cause it to be "so slow" for that reason? Maybe the reason is another? Personally, I once had Magit act real slow at times because git-annex had added some git hook for something that I didn't need. Just removing that hook improved performance massively. Perhaps something similar is happening. Also, I'm not sure Emacs Lisp ca…

Unfortunately, it's pretty slow on macOS, as well. I love Magit, but there are times when I feel like it's hindering me more than helping due to the performance.

I noticed better performance using native-comp in magit (and the rest of emacs for what it’s worth) on macOS. Might be worth a shot!

Re: Magit, the magical Git interface (2017)

#258

Post by faustlast »

amai wrote: post #153

Git doesn't need a more complex interface. It needs a more simple interface. Magit is a complete failure in this respect. The author seems to think it is easier to remember "Ctrl-x g" than "git status". Instead we need more tools like Legit: https://frostming.github.io/legit/

This idea of remembering keybindings in emacs is false. You need a command, a function call, the keybindings are just for convenience...

Re: Magit, the magical Git interface (2017)

#259

Post by [deleted] »

PaulDavisThe1st wrote: post #224
amake wrote: post #203

Earlier quoted context omitted.

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

[deleted]

Re: Magit, the magical Git interface (2017)

#260

Post by b3morales »

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,…

Rebasing has a simple rule: it is perfectly fine as long as you haven't shared those commits.*

Perhaps git should have a "checked rebase" command that requires a `--force` flag if there's an upstream branch set.

*And even then it's kind of okay as long as no one else has made commits on top of the rebased commits.

Post reply on HN