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

311–320 of 550 posts

Re: New in Git: switch and restore

#311

Post by chungy »

greatgib wrote: post #168
bicolao wrote: post #4

You don't need -- as much in the "git restore" example. With git checkout it may be necessary to separate the branch and the paths with "--" but since "git restore" does not take a branch (except with -s), doing this is totally fine git restore test.txt

Thank you very much for this info. From the article, I was thinking that it was again a stupid confusing design for the cli to requires the -- even with a dedicated command. One main issue with git is to not be consistent and logic with the comments. Always to use different way or option abbreviation for different command. For example having a space or a slash between repo and a branch in a command.

-- is typically to end argument processing and to treat all further ones as files. With git-restore, it's probably only relevant if you happen to have files in your repo that begin with hyphens. A fairly unusual situation, granted, but not forbidden.

Re: New in Git: switch and restore

#312

Post by Lordarminius »

samatman wrote: post #295
Lordarminius wrote: post #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]…

I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file! I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit. I do run `git diff` first to see what I've changed, and if the diff has u…

True, an error. Corrected.

Re: New in Git: switch and restore

#313

Post by edoceo »

b3morales wrote: post #283
ketzu wrote: post #220

Earlier quoted context omitted.

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

I often see people self-describe as noobs when asking technical questions, for example in programming Reddits. I couldn't say that I understand the reason for it, though.

Noob is the first step to being a master. So, those "noob"s are indicating they're early in the process.

Re: New in Git: switch and restore

#314

Post by crazygringo »

hedora wrote: post #218
laumars wrote: post #187

Earlier quoted context omitted.

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…

> Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos

What about people who have totally figured out the CLI but still prefer to use a GUI?

I don't get why people act like it's either/or.

Re: New in Git: switch and restore

#315

Post by GeorgeTirebiter »

gumby wrote: post #282
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…

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…

How should one go about achieving a 'decent fundamental understanding' (specific pointers, if you have them). And, how much time must one devote to being a 'good enough git guru'? (and, it surprises me that gitless is not more popular: https://gitless.com/ )

Re: New in Git: switch and restore

#316

Post by jhayward »

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…

Oh, boy, do you really want to say that? I have some questions about numerical algorithms that you probably rely on every day for you.

Re: New in Git: switch and restore

#317

Post by agilob »

tsimionescu wrote: post #176
agilob wrote: post #116

Earlier quoted context omitted.

I feel you. I was recently hired to help with svn to git migration and Java upgrades from 5-7 to 8 (due to my previous experience with such migrations). When I joined they already had a plan. They told me no one will be using command line. They are currently discussing which GUI to use and everyone will have this GUI installed by default, git command will be discouraged as non-standard approach, windows users will no…

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!

Re: New in Git: switch and restore

#318

Post by pjmlp »

chris_j wrote: post #292
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.

What would you recommend using instead of git? (Myself, I've been heard complaining that git is overly complex, but the source code control systems that I used to use before git include Subversion, CVS and various Rational products and I have no desire to go back to any of them.)

If I had the choice just mercurial or yes, Subversion does just fine, it is anyway how 99% of people actually use git.

Re: New in Git: switch and restore

#319

Post by bob1029 »

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.

This is true on so many other levels too. My job isn't to be an AWS expert, VIM master, Visual Studio ninja, Unix professor, et. al.

My job is to make the customer happy. That is it. If the customer is happy, my project managers are happy, the executives are happy, the investors are happy. When all of your bosses are happy, you can get away with absolute murder. No one gives you shit about anything. Production went down because you fucked up? No big deal - that was like the first time in 18 months we had any problems, and the customer can't even see these things through all the magical features get to play with day-to-day. Need to take the entire afternoon to play overwatch because [arbitrary fuck you reason abc]? No one cares as long as you didn't have a scheduled meeting. In this realm, your mind is free to explore side projects without fear of reproach or guilt-trip. Tasks are executed with confidence and calm. Innovations are more frequent and valuable. People are actually relaxing in their time off and enjoy working for their employer.

When the customer is pissed off, it is like entering into Doom Eternal as a non-player character. At every turn you begin to anticipate a heated conversation about missed target XYZ and incident ABC. Each ding of your outlook bumps your blood pressure by 20-30% before you even see the subject line. Your executives start taking damage from your customer's executives. Investors begin executing difficult queries regarding long-term viability. NO one is sleeping anymore. Side projects? Are you fucking kidding me? Not in this hell.

So, when someone in my organization starts giving me the run-around about [pedantic greybeard doctrine which adds 10x overhead to a process], and also has no business value to show for said run-around, I begin to shut things down pretty quickly. If you want to play nuclear release authorization simulator every time you need to check in source code, please do this on your own time. Even the most elite hacker rockstars like to use GUI tools so they can see what the fuck is going on without making their eyes bleed every 10-15 minutes due to terminal character display restrictions.

Re: New in Git: switch and restore

#320

Post by fermentation »

tkuraku wrote: post #145

I think sublime merge is pretty close to the optimal git GUI, https://www.sublimemerge.com/ . It uses standard git commands and terminology and allows you to add custom git commands to the GUI. Unlike Sourcetree is cross platform for Windows/Linux/Mac and includes a merge tool. I think command line git and Sublime Merge git translate back and pretty easily.

How do folks like this for reviews? I’m switching to git for a new job and the process is a bit overwhelming compared to mercurial
Post reply on HN