Live data from Hacker News

New in Git: switch and restore

banterly.net

331–340 of 550 posts

Re: New in Git: switch and restore

#331
post #317

Earlier quoted context omitted.

You should have recommended Emacs Magit just to see the looks on everyone's faces.

Funny enough, one argument against cli git was 'vim' as commit text editor ;) Maybe emacs would convince them!

Did changing GIT_EDITOR to something else not cross their minds? Or did they not even bother to check if it can be changed?

Re: New in Git: switch and restore

#332
post #282

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

I don’t completely agree. > My job isn’t to use git, it’s to write specialist software. I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!). So, as I think most peop…

I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it.

Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally important tools we use every day if we work in a team. You aren't doing your job if you don't care about how your code interacts with your team and your deployment. Like an architect who doesn't know how to use a drafting table.

It's incredibly frustrating that people let their egos stoke them into this idea that tooling is beneath them. It's almost certainly the cause of an incredible amount of bad software, even though much of its code is, I'm sure, quite clever in a vacuum.

And I'd rather work with a hundred programmers who know how to use their tools than one programmer who looks down on them for it.

Re: New in Git: switch and restore

#333

Earlier quoted context omitted.

A more apt comparison would be to using a saw vs using a saw with gloves on. With gloves it's safer and more comfortable, but you're not quite as in touch with the wood as you would be without one. Without gloves you feel badass because you don't care about safety, and you might be able to carve out some slightly more intricate things. Either way the outcome is roughly the same and it really doesn't matter what your…

I flagged this because this is extremely dangerous advice. DO NOT use gloves with a table saw, jointer, etc There are exceptions, but if you want a simple rule: DO NOT use gloves with power tools It is extremely dangerous. You can take an injury that would've been a nick on the finger and turn it into a lost hand.

I had a hand saw in mind...

Re: New in Git: switch and restore

#334
post #194

Earlier quoted context omitted.

“Hey can you help me? I stood up a kratr pod and it’s lined to fundle but for some reason when I try to press the bin tree to the overlay layer the reznik instance on my laptop says ‘out of tokens’. Have you ever encountered this?” No, no I have not.

Having been troubleshooting computers since I was literally 8 years old (like I'm sure many of us here have) I feel reasonably comfortable I could at least be helpful solving this problem as well. Every problem I have to troubleshoot is almost by definition one I've never encountered before.

I can help. It doesn’t mean I’ve encountered it before.

Re: New in Git: switch and restore

#335
post #105

Earlier quoted context omitted.

We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's…

No, we use it because it's superior to the competition. It's much better than Subversion that was the standard before git arrived. And it's much better than Mercurial that was competing to become the source control system to replace SVN.

As someone about to migrate from Mercurial to Git i absolutely agree that Git is the superior tool.

Pull Requests were never going to happen with Mercurial and it's also not possible to delete a branch without some black magic server-side.

And with Git hopefully it will be possible to move to Trunk-based development, although that requires a lot more than just switching to Git.

Re: New in Git: switch and restore

#336

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

Except for 99% of all git day to day tasks are done with like 7 commands. Git commit Git checkout Git merge Git pull Git push Git rebase Git stash I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

I seem to use cherry-pick at least monthly, as well as log and diff.

Re: New in Git: switch and restore

#337
post #138

Earlier quoted context omitted.

See my earlier comment here: https://news.ycombinator.com/item?id=27580478

Regarding your first point (and I think some of the commenters in that thread also address this already) is that as long you don't have uncommitted changes, you're safe. You're right that a lot of git-commands mess with uncommitted changes in hard-to-recoverable ways, but once changes are committed, there's almost no way to mess anything up, you can always go back to the previous state (git reflog telling you which c…

Yeah. That clarified everything.

Re: New in Git: switch and restore

#338
post #82

Earlier quoted context omitted.

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push. I say "just rebase your branch" and I can see the panic grow in their eyes.

> I say "just rebase your branch" and I can see the panic grow in their eyes. The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line. Not all GUIs support it though (I think SourceTree gives up if there's a conflict), in fact it's a bit of an acid test for a Git GUI. The Jetbrains IDEs (PyCharm, CLion, IDEA, etc.)…

> The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line.

This is an argument for a good GUI diff/merge tool, which is not necessarily the same thing as an argument for a GUI Git client; I think the two uses are being conflated a lot throughout this comment thread. I have Kaleidoscope set as my default mergetool and difftool, but I'm still working with the git CLI nearly all the time. (I use Gitup on the occasions I want to stage changes to individual sets of lines in the same file as multiple commits, and exceedingly rarely if I'm trying to do something frightening with a local as-yet-unshared feature branch. There are times being able to undo with Cmd-Z is really helpful.)

Re: New in Git: switch and restore

#339

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

Wonder how many command line enthusiasts are using gitflow to make things even simpler than sourcetree.

Re: New in Git: switch and restore

#340
post #282

Earlier quoted context omitted.

I don’t completely agree. > My job isn’t to use git, it’s to write specialist software. I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!). So, as I think most peop…

I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it. Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally impor…

I don't understand how "using a GUI to drive this tool" instead of "using a CLI to drive this tool" means someone doesn't understand version control, doesn't care about how their code interacts with their team, or doesn't know how the tool works.
Post reply on HN