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…
New in Git: switch and restore
221–230 of 550 posts
Re: New in Git: switch and restore
#222It 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.
Re: New in Git: switch and restore
#223Earlier 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.)…
Re: New in Git: switch and restore
#224Earlier 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?
Re: New in Git: switch and restore
#225Earlier 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…
Re: New in Git: switch and restore
#226A 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…
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
#227Earlier 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…
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
#2281. 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
#229Earlier 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.
Re: New in Git: switch and restore
#230Earlier 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…
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.