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

211–220 of 550 posts

Re: New in Git: switch and restore

#211

Post by PaulDavisThe1st »

joseluis wrote: post #77
thecupisblue wrote: post #58

Earlier quoted context omitted.

>Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. The depressing thing is I'm not talking just about off-the-shelf newbies, I'm also talking about experienced devs. >Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity. Yes, unfortunately, this is b…

the solution I believe would be to focus on creating simpler tools, and by that I mean tools with at least the same usefulness/as powerful as the ones we have now, but with much less cognitive burden, with better interoperability and composability by using simple standard data interchange formats.

If you really believe this, then I don't believe that you understand what the job of a powerful revision control system is.

The "cognitive burden" of git comes as much from the tasks that it is occasionally required to make possible than anything else.

If the only git commands you ever use are push, pull, commit and checkout then its a very simple system with very little cognitive burden. But one day, you may need to perform a truly complex task with git that a simpler system with much less cognitive burden would just not allow.

I do not understand how "data interchange formats" are an issue here. What do you want to inter-operate with?

Re: New in Git: switch and restore

#212

Post by foepys »

wizzwizz4 wrote: post #209
PaulDavisThe1st wrote: post #208

Earlier quoted context omitted.

> 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 not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. Imagine if you knew a cabinet builder who said: "My job isn't to use a table saw, it's to build beautiful cabinets. If I get…

Version control isn't a tool I use. It's the filesystem I store my files in.

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

Re: New in Git: switch and restore

#213

Post by tryingtogetback »

aniforprez wrote: post #193
tryingtogetback wrote: post #95

Earlier quoted context omitted.

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…

You are contradicting yourself and making my point for me.

janitor is an abstraction (you trust a janitor to operate with a professional tool for you) and you are completely right, git GUIs (just like a janitor) are a liability.

Re: New in Git: switch and restore

#214

Post by zkldi »

Shywim wrote: post #202
dagw wrote: post #182

Earlier quoted context omitted.

Isn't that just being incredibly lazy. Surely a reasonably experience person like yourself should be able to read the error message and at least get a rough idea about what the problem is. Then from there explain how you would fix it on the CLI and try to map that onto the GUI. Most Git GUIs map fairly closely to the underlying git model. Why not just say the truth "I could help you, but it's not my job, so I'm not g…

> Most Git GUIs map fairly closely to the underlying git model. Maybe, but most Git GUIs don't provide clear error messages. This is the case of VSCode, which my teamates keep using. When you use Git CLI you can just have the original error message and know what's wrong. I was also burned by sourcetree some years ago where it lost part of my code while doing a merge I didn't even understand. I am not a Git expert. Bu…

You can see the original error message in vscode by clicking "output" and navigating to Git in the dropdown.

Re: New in Git: switch and restore

#215

Post by jonwinstanley »

akx wrote: post #206

These features were introduced in 2019 (and have been featured in git's help texts since). Serious question - Why is it that they're called new two years later? Is it that no one cares to read git's prompts or release notes?

The author did say that had only recently discovered these commands. Unsure why they said they were new, maybe they were kidding?

Re: New in Git: switch and restore

#216

Post by ekster »

wizzwizz4 wrote: post #209
PaulDavisThe1st wrote: post #208

Earlier quoted context omitted.

> 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 not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. Imagine if you knew a cabinet builder who said: "My job isn't to use a table saw, it's to build beautiful cabinets. If I get…

Version control isn't a tool I use. It's the filesystem I store my files in.

Would you use an accountant who doesn’t think it’s important to know how to file documents, or that their file cabinets are even a tool of the trade?

Re: New in Git: switch and restore

#217

Post by z77dj3kl »

PaulDavisThe1st wrote: post #208
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…

> 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 not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. Imagine if you knew a cabinet builder who said: "My job isn't to use a table saw, it's to build beautiful cabinets. If I get…

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 personal preference is.

Re: New in Git: switch and restore

#218

Post by hedora »

laumars wrote: post #187
crazygringo wrote: post #165

Earlier quoted context omitted.

First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help. And second, what exactly mystifies you about what e.g. SourceTree menu commands do? They map clearly and intuitively to CLI commands. If you have "no idea" what it's trying to do then you're not even trying to be helpful. You're just being condescending…

I get you disagree with the GPs post but “noob” isn’t offensive. What’s offensive is their lack of support for colleagues (which reads like a potential issue with their own ego: where they didnt want to be shown up in an unfamiliar UI). But their post reads exactly the same if you substituted “noob” for “newbie”, “junior”, “inexperience” etc. What we need to do is get passed this ridiculous mindset some have that not…

I don’t think they meant noob as a pejorative.

Anyway, I’ve been the “resident git expert” before, and even just supporting competent CLI users is miserable once the team grows beyond 30 or so people. I can’t imagine trying to then reverse engineer and debug a half dozen crappy GUIs.

Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos (both by admitting bozos and by chasing non-bozos out).

Re: New in Git: switch and restore

#219

Post by PaulDavisThe1st »

thesuperbigfrog wrote: post #119
pjmlp wrote: post #55

It is ironic that Linus hates C++ so much, and then proceeds to create what is for all practical purposes, the C++ of source control systems.

He was "scratching his own itch" (see http://www.catb.org/esr/writings/homesteading/cathedral-baza... ). Git was written to meet the version control requirements of the Linux kernel. It works well for that project's needs which are an outlier for most development needs unless you are working at FAANG scale.

Git is a perfect match our project's needs, which are so far from FAANG scale that it would be a joke to even compare them.

In our case, fully distributed development (no developers live or work within 1000 miles of each other), public repository, welcoming 3rd party PRs, strong use of topic branches, fully rebase-not-merge workflow. 600k lines of C++, 21 year history, on the order of 100 contributors, 2-3 core developers at any point in time.

Re: New in Git: switch and restore

#220

Post by ketzu »

gavinray wrote: post #102
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"…

Eh, that term seems to have fallen out of favor compared to when I was a growing up but I don't think it necessarily has a negative connotation. I remember being in programming and software related IRCs at 10-11 years old having no earthly clue what in the fuck I was doing, asking adults questions and getting called a "noob". Well, yeah, it was true. (I also made damn sure they had no idea I was a child.) They could…

My personal experience around noob is covered by the ones I found on ~~most~~ edit: the most high search-ranked online explanations: Mostly negatively conotated, deregatory version of newbie. Often associated with people not sufficiently able to learn or at least not learning on their own.

Examples:

* https://en.wiktionary.org/wiki/noob

* https://www.etymonline.com/word/noob

Examples not containing the negative connotation:

* https://www.merriam-webster.com/dictionary/noob

* https://neologisms.rice.edu/index.php?a=term&d=1&t=2471

It might be something used quite differently by two similar groups, so it is good to be aware that other people may use it the other way.

Post reply on HN