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

171–180 of 550 posts

Re: New in Git: switch and restore

#171

Post by bicolao »

scotty79 wrote: post #151
411111111111111 wrote: post #21

Earlier quoted context omitted.

It's usually not necessary for checkout either

What does -- do exactly?

-- in git is usually used to mark the end of options. After --. --foo means an argument --foo, not the option --foo.

Git checkout and a few other commands also use it to separate branch and the rest of paths, because you could specify like this

    git checkout branch path1 path2
    git checkout path1 path2
    git checkout branch # what if there's a file named "branch"?
-- help disambiguates that by being between the branch and the paths, so

    git checkout branch -- # always checkout a branch
    git checkout -- path1 path2 # always checkout paths
    git checkout branch -- path1 path2 # same, but disable disambiguation logic

Re: New in Git: switch and restore

#172

Post by crazygringo »

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…

Seriously, seeing the commit tree laid out with colored lines is essential to me. A glance at the interface lets me know exactly what state the repository is in. Just like you say, it's less mistakes. Which is precisely one of the benefits of good UX.

Going from SourceTree back to the command line would be a huge step backwards for me. I still use the command line sometimes because there's advanced stuff SourceTree can't do. But for most of my basic everyday operations, the command line is just inviting me to make little accidental mistakes every so often because the state of the repository and branches isn't obvious at a glance.

I only see upside to using an IDE, zero downside. (I've never had SourceTree "corrupt" my repository, and all its commands do exactly what I expect -- it's just running the git commands I'd be typing out anyways.)

Re: New in Git: switch and restore

#173

Post by onionisafruit »

makeitdouble wrote: post #84
Vinnl wrote: post #3

It's not really new anymore, but still way underused, so it could certainly do with more attention. Git's UI has become better, but they can't really remove the old UI and tutorials using those, so people keep sticking to that.

These new commands make a lot more sense, but the weird thing is they don’t bring anything else to the table. They behave exactly like the existing ones, so much that anyone that really cared could have just aliased them. So is there any incentive to switch for the people who went through the trauma of burning the old ones in their soul ? (I often heard that knowing how it works internally makes git commands feel nat…

I had git-checkout syntax burned into my soul. I switched to switch/restore a year or so ago and am happy to be mostly unburdened of git-checkout. I say mostly because I still use it in scripts so they work with old git versions.

Re: New in Git: switch and restore

#174

Post by levzettelin »

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…

Looking at diffs on the command-line is cute and all, but for anything substantial I doubt this will ever be as good as using a proper GUI interface. I like "meld". You have to install it, then run

  git config --global alias.meld '!git difftool -t meld --dir-diff'
and after that you can do:

  git meld                   # like "git diff"
  git meld --staged          # like "git diff --staged"
  git meld branchA branchB   # like "git diff branchA branchB"

Re: New in Git: switch and restore

#175

Post by ozim »

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…

By "properly" - I mean not messing up your own or others work in unpredictable ways.

My dev team uses git properly. They are not some masters in a way that they know each command by heart. They often use visual tools or what is built into IDE. We just have general guidelines and everyone knows how to do basic moves like "get code from remote", "merge others work into your local changes".

We had people who always have problems like "GIT ate my homework", well they don't work with us anymore so maybe it is a selection bias.

But I don't think my team members were NOT studying git for months to get to that level, it just came as they go along. Visual tools help a lot really.

In the end I expect someone with any abstract thinking capabilities to be able to use GIT "properly" after a week of working within the team. Like pull new changes every day, create new branch, create a pull request, merge new changes into your working branch.

Re: New in Git: switch and restore

#176

Post by tsimionescu »

agilob wrote: post #116
intellix wrote: post #83

Earlier quoted context omitted.

I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you

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.

Re: New in Git: switch and restore

#177

Post by wpietri »

thecupisblue wrote: post #36
some_developer wrote: post #16

I used to know lot of terminal commands but I'm seriously falling behind due to jetbrains integration which covers 99% of my daily use case. Together with local history, I've never "lost" work in years. Never heard of switch /restore and will probably forget about it the next time I'm on the terminal. Rebase and interactive Rebase is so well integrated for my use cases and I feel much more productive without having t…

> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with. I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never nee…

This attitude mystifies me. The whole point of computers is to solve problems well enough that most people don't have to understand the machinery.

It is literally impossible for us to understand how everything we use works. We expect a compiler to just compile things and work; nobody is ranting about how modern developers are lazy because they can't hand-verify the compiler is outputting the right opcodes. Nobody is ranting about how web developers are lazy because they can't debug a browser runtime and its interface to the OS's rendering primitives. Can some people do those things? Sure. Do we imply character flaws for the 98% of developers who have focused on other things? No.

If this old-man-yells-at-clouds, good-enough-for-grandpa-so-its-good-enough-for-me style were the dominant approach in our industry, we'd still be working with punch cards and fanfold printer output. Thank goodness it isn't. Instead of having a million developers adapt to git, git should adapt to the million developers and free up their time for doing something that actually matters to a user.

Re: New in Git: switch and restore

#178

Post by uses »

I use restore quite a lot but it kind of terrifies me that it can erase any amount of uncommitted work if I type something wrong. "git restore ." is basically "delete everything that I don't have a backup of".

Re: New in Git: switch and restore

#179

Post by SAI_Peregrinus »

bspammer wrote: post #123
yunohn wrote: post #78

Earlier quoted context omitted.

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”. Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git. The goal of being a programmer is to produce cool things, not to duel with your to…

The irony with git is that the underlying data model is far simpler than the user interface implies. People assume git is complicated because the user interface is complicated, but it really is very simple under the hood. So much so that you can write your own basic version of git in a couple of hours: https://wyag.thb.lt/

The problem is that git leaks the underlying data model all over the place, even where it's unnecessary to actually controlling versions. It's a nice data model, but the user view shouldn't expose it. The data model is an implementation detail, but git treats it like a show & tell.
Post reply on HN