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

331–340 of 357 posts

Re: Magit, the magical Git interface (2017)

#331

Post by matheusmoreira »

Dylan16807 wrote: post #318
matheusmoreira wrote: post #129

Earlier quoted context omitted.

> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…

> I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? Trying to stash some of the changes is pretty annoying, yes. New files don't want to cooperate with stashing, and there's no way to stash just staged things like making a commit; you have to use -p.

> there's no way to stash just staged things like making a commit

That would be a nice feature!

Re: Magit, the magical Git interface (2017)

#333

Post by jboynyc »

xvilka wrote: post #321
FrontAid wrote: post #275

Earlier quoted context omitted.

I did see the commits, but the last release was almost three years ago. That is not necessarily bad. I was just wondering whether it still works well or there are any quirks.

Many Vim plugins abandoned the release model since most Vim and NeoVim package managers focus on fetching latest git HEAD for every installed plugin.

Yes, good explanation. Case in point: Neogit has never tagged a release: https://github.com/TimUntersberger/neogit/tags

Re: Magit, the magical Git interface (2017)

#334

Post by gpderetta »

Dylan16807 wrote: post #318
matheusmoreira wrote: post #129

Earlier quoted context omitted.

> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…

> I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? Trying to stash some of the changes is pretty annoying, yes. New files don't want to cooperate with stashing, and there's no way to stash just staged things like making a commit; you have to use -p.

You have to do it in two steps with --keep-index.

Or use magit that has a stash index option.

Re: Magit, the magical Git interface (2017)

#335

Post by matheusmoreira »

rich_sasha wrote: post #293
matheusmoreira wrote: post #226

Earlier quoted context omitted.

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

I’d like something like: - git revert {rev} to nuke changes and go back to how the world was - git uncommit to return to the state literally before git commit - git unstage to unstage a file The latter arguably should go with git stage but it’s a bit late for that. NB git add and git rm are totally not inverse operations... So then I can uncommit, and unstage if need be. Reverting is for discarding changes, and shoul…

> git uncommit to return to the state literally before git commit

This is ambiguous because there are many such states.

1. Clean working tree, before you began hacking on the code.

2. Modified working tree.

3.1. Modified working tree with staged changes.

3.2. Clean working tree with staged changes.

It's impossible to know which state you want to go back to without telling git. That's what hard, mixed and soft resets do: they bring you back to states 1, 2 and 3.2, respectively.

The default is a mixed reset. I suppose state 2 is what most people want when they try to undo a git commit. So it already does the right thing by default, no?

The only remaining problem is the git reset argument. An undo command will always reset to the previous commit, there should be no need for arguments. Stuff like HEAD^ or HEAD~1 is quite obscure to the uninitiated. We could certainly have a git undo command that runs git reset HEAD^ and allows hard and soft resets. Not sure why it doesn't already exist. Has anyone ever attempted to get that merged into mainline git?

Re: Magit, the magical Git interface (2017)

#336

Post by clojureyoureyes »

gigatexal wrote: post #322
rich_sasha wrote: post #255

Earlier quoted context omitted.

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.

The age old adage applies here: know your tools.

Software is for people, not for software itself.

I want to get things done fast and with less cognitive load, magit allows me to, git doesn't.

Re: Magit, the magical Git interface (2017)

#337

Post by clojureyoureyes »

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…

> Yeah, git is certainly a low level tool.

> I too google the commands I don't use often.

So, spend more time getting the same result is fine for you?

Re: Magit, the magical Git interface (2017)

#338

Post by matheusmoreira »

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…

The reflog is awesome! It keeps pointers to commits that have been dropped, rewritten by rebases, stuff like that.

Git is garbage collected, even if a commit is dropped from a branch it won't simply disappear immediately afterwards. The object is still in the git repository and it can still be reached, most easily through the reflog. Only when garbage collection is performed will any unreachable commits be deleted.

Re: Magit, the magical Git interface (2017)

#339

Post by clojureyoureyes »

radarsat1 wrote: post #142
matheusmoreira wrote: post #129

Earlier quoted context omitted.

> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…

Same. After trying a couple of times, I haven't been able to get used to magit, and I gave up. I'm very used to the git command line interface, and magit is just too different from that. For instance, it seems to assume I want to operate only on a file, whereas most of the time I want to operate on the whole repository. I have no idea why someone would want to work like that. I found it was taking a lot of extra rese…

> I have no interest in trying to memorize which hotkey does what, and how to bend yet a new interface to my will

you don't have to, most of the time `git subcommand` counterpart is just `M-x magit-subcommand`

Re: Magit, the magical Git interface (2017)

#340

Post by matheusmoreira »

clojureyoureyes wrote: post #337
matheusmoreira wrote: post #215

Earlier quoted context omitted.

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…

> Yeah, git is certainly a low level tool. > I too google the commands I don't use often. So, spend more time getting the same result is fine for you?

Depends on the result. I do interactive rebases extremely often, I don't have to look up how it works.

Sometimes I have to use some command I'm not familiar with. Sometimes familiar commands gain new options. It's perfectly okay to use some reference for that. Also, "more time" is like 1 minute.

Post reply on HN