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

New in Git: switch and restore

banterly.net

Post reply on HN
Print view View original

191–200 of 550 posts

Re: New in Git: switch and restore

#191

Post by asimpletune »

wpietri wrote: post #188
asimpletune wrote: post #181

Earlier quoted context omitted.

Submitting a patch would start with filing an issue right? And I assume in that venue the maintainers would clarify their intent. If help were indeed needed then I’m sure the maintainers would be relieved to get some help fixing the documentation but. In any case, the suggestion of submitting a patch when you notice a problem doesn’t deserve downvotes. That’s not throwing shade, at all.

There are ways to suggest submitting a patch that don't come across as dismissive, as a way to shut down a legitimate complaint. But this wasn't one of them.

Ok, and why is that?

Re: New in Git: switch and restore

#192

Post by plorkyeran »

lisper wrote: post #94
hkopp wrote: post #49

My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you have long sentences where only a comma changed or some other typo. With git diff, the two lines are shown, with --color-words, only the changed symbol is highlighted. The option --color-words also works with git show. I even made aliases for them: git cshow and…

> Other than that, I recommend that people learn to use git properly. Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if…

The alternative is trying to use git while doing your best to avoid learning anything more about it than you absolutely have to, which is what most git users do. This is a great strategy for many tools, but git is not one of them.

Re: New in Git: switch and restore

#193

Post by aniforprez »

tryingtogetback wrote: post #95
zarzavat wrote: post #91

Earlier quoted context omitted.

It's more like getting the dental assistant to operate the autoclave.

Endless opportunity for analogies here. The gist is that you are delegating all sensitive versioning and versioning history management operations to a 3rd party with extremely limited capabilities, 3rd party you know nothing about (effectively a black box). We thrive on abstractions, but unfortunately in case with versioning and git in particularly, GUI apps is a wrong one.

Your analogy is completely awful

The janitor knows nothing about dentistry. The git GUI knows plenty about it and the devs make it their job to know it too. A janitor is not an abstraction, he's a liability. If a GUI abstraction helps me get the job done faster, I really don't see the problem. Plus almost every one of them fully state the commands being used to perform every action and have logs you can parse. I used to use Sublime Merge and now use Fork and both have this

Re: New in Git: switch and restore

#194

Post by dagw »

IgorPartola wrote: post #106
FunnyLookinHat wrote: post #88

Earlier quoted context omitted.

I've had similar experiences with git or other tools - not being able to help a junior dev because the GUI they're using is obfuscating whatever it is the underlying tool is trying to do. I think the irony is that we've got this insanely complex version control system that actually could have several valid use cases for what is likely a common path for users in a GUI. I'm also not sure referring to people as "noobs"…

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

Re: New in Git: switch and restore

#195

Post by Shorel »

quietbritishjim wrote: post #100
oauea wrote: 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.)…

I use Meld in case there are conflicts of these types. The CLI can be configured for that, and mine is set up that way.

But truly, I never just use plain pull, but pull --rebase, and I have not experienced such a conflict in years.

The commit history also stays a bit more linear. (Other developers use normal pull).

Re: New in Git: switch and restore

#196

Post by galangalalgol »

voakbasda wrote: post #136
zwischenzug wrote: post #108

Earlier quoted context omitted.

This is exactly what motivated me to write Learn Git The Hard Way - I was surrounded by people who depended utterly on IDEs and got themselves into terrible states that based on models that were refractions of what the the (universally available) CLI gives you. The best example of this was when I worked with a project with 12 dev teams that didn't rebase. They asked me where a commit came from, and when I ran 'git lo…

Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of t…

I'll admit as a 20yr c++ developer, I don't know what rebase is or when to use it. I've only been using git for a few years, cvs before that. I commit and push often, then do a merge request via a web portal gui(bitbucket or gitlab), then merge it squashing commits again using the gui.

Re: New in Git: switch and restore

#197

Post by whiddershins »

restore is a bad name for this action IMO. It is extra pandering to beginners, by targeting what the maintainers maybe believe is the most common use case.

Thats’s why checkout is such a great name.

Maybe ‘apply’ would be good.

My git-fu is often lacking, but I don’t blame git for being hard, I blame myself for not taking the time to be amazing at a tool basically everyone uses all day every day.

It’s silly not to know git. It might be the most used development tool in the world.

Re: New in Git: switch and restore

#198

Post by PaulDavisThe1st »

geofft wrote: post #166
rbreaves wrote: post #140

Earlier quoted context omitted.

You assume that the creator of one of the.. if not the largest open source projects on the planet might not understand the issue at hand better than literally anyone? That seems arrogant. I imagine more thought & care went into git than you can fathom.

This isn't about "understanding the issue at hand," this is about UX development. Linux is, very intentionally, a piece of software which does not have "easy to understand for non-experts" in its design goals. You generally interface through Linux with system call wrappers provided by a libc (or another specialist library for other interfaces like libfuse or libnetfilter or whatever), not directly. Linus is, quite ob…

The difference between the kernel development model, and some putative "typical other" development model merely changes which git commands/tools get used to handle getting stuff into a particular branch on the canonical repo.

It has no impact on the underlying concepts that make git scale well, cover 100% and 100% remote cases equally well, and provide deep under-the-hood concepts that can be deployed in exceptional circumstances.

Re: New in Git: switch and restore

#199

Post by magoon »

aetherspawn wrote: post #73

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…

Commands are explicit and shareable. If you’ve mastered then good on you, but it makes you an island.

Re: New in Git: switch and restore

#200

Post by nine_k »

Once upon a time, someone decided to overload `checkout` with a bunch of semi-related actions, apparently for convenience. The day these patches were accepted was a sad day.

It's great to see that someone took time to restore sanity. I'll switch to these commands now.

Post reply on HN