Live data from Hacker News

New in Git: switch and restore

banterly.net

221–230 of 550 posts

Re: New in Git: switch and restore

#221

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…

In your anecdote, git wouldn’t even qualify as a tool, it would be the weird storage space with an over-inflated sense of importance.

Re: New in Git: switch and restore

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

99% of developers that have to deal with git complexity aren't working at FAANG scale.

Re: New in Git: switch and restore

#223
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.)…

Magit[1] is also excellent. And like all good git tools it exposes a log of what it did. Unfortunately it doesn't work so great with megarepos, but I understand that's being worked on. One area where this tooling is vastly superior to the command line is adding hunks instead of files to a commit, making it much easier to have a sensible history while allowing programming in a more natural style.

[1] https://magit.vc/

Re: New in Git: switch and restore

#224

Earlier quoted context omitted.

I have 10 years of git cli and I use GitHub desktop or Sourcetree most of the time. I started using using a git IDE to help support the team members that weren’t experienced in git that chose to use one. I work in games and a lot of game developers mostly know Perforce. I would never brush off a team member with “cannot help you”. I’m a git expert and I will figure out what’s wrong and fix it.

But are you an expert in the IDE? Are they having a problem with git or are they having a problem with the IDE?

It’s usually a mix of both ide and git issues. And yes I’ve become an expert in using Sourcetree and GitHub desktop. I actually like GitHub Desktop a lot and use it for most dev now.

Re: New in Git: switch and restore

#225

Earlier quoted context omitted.

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

There were other solutions, much less complex to deal with than git, but hey, they lacked the luxury of being an hard requirement to deal with Linux kernel and related eco-system.

Re: New in Git: switch and restore

#226

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…

> But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work

You chose a strange analogy, because CNC woodworking is far and away the superior choice over hand tools for producing cabinets. CNC cut and drilled wood is going to be orders of magnitude cheaper, more accurate, and allow the cabinet professional to focus on what really matters (installing them properly) rather than wasting huge amounts of time trying to do everything the manual way.

Ironically, this might be a great analogy to support the OP's point: Someone who gets so caught up in the tools and methods and doing everything the manual way for the sake of flexing their knowledge is at risk of wasting a lot of time and energy.

Personally, I have a lot of fun doing things the hard, manual way when I'm working on a hobby project. But when it's time to get work done, I choose the efficient abstractions and tools that let me focus on the core work without wasting time.

Re: New in Git: switch and restore

#227

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…

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…

Speaking as a person who lost half a thumb to a table saw ...

the difference in your analogy emerges when someone wants/needs you to carve out something more intricate, and you say "it's not my job to be able to do this without gloves".

Re: New in Git: switch and restore

#228
As a helpful aside, in my experience, there are only about a dozen or so Git commands you need to do ninety percent of your work. You don't need to become a git zen master right away.

1. git init: to start a new repository

2. git status: checks your current state

3. git add -A: To begin tracking files

4. git commit -am: Commit all changes in the working directory with a message added on

5. git switch -c [branch name]: Create a branch and switch to it. (git checkout -b will do the same thing)

6. git switch [branch name]: switch between named branches

7. git merge[branch]: merge named branch into current branch

8. git branch [branch name] -D : delete branch if not tracked

9. git log --pretty=oneline: show a graph of commit history.

11. git push

12. git clone [repo]: Copy of a project/file onto your local computer.

The comments also contain some additional advice. Here is a good introductory video: https://www.youtube.com/watch?v=2sjqTHE0zok

Re: New in Git: switch and restore

#229

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.

Yup - Every darn time. Reminds me of "How it feels to learn JavaScript in 2016" https://news.ycombinator.com/item?id=12628921

Re: New in Git: switch and restore

#230
post #166

Earlier quoted context omitted.

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…

Correct, it has no impact on the internals of Git, which was my point. Git's internals are used by both the kernel development workflow and the GitHub-style workflow, and Linus designed it well.

The conversation is about the user experience of using Git - its CLI design, etc. It is entirely about "merely" what commands are being used. TFA is about new Git commands, not about any changed internals. Or, in the case of Sourcetree, it's about not using any of "Linus's" interface to Git (which, again, wasn't written by Linus) but interacting with the same Git internals.

Post reply on HN