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

111–120 of 550 posts

Re: New in Git: switch and restore

#111

Post by thecupisblue »

600frogs wrote: post #26
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…

I currently use a third-party git GUI (GitKraken atm) but I also use jetbrains products, am I missing out by not using the integrated git functionality? If so, is there a tutorial or guide you could recommend, or is it all fairly self-explanatory?

Jetbrains Git integration is quite self-explanatory - if you're already using GitKraken, you're not missing out much except being able to do it from your IDE instead of another tool. Maybe conflicts are a tad easier due to same syntax highlighting style and ability to edit on the go.

Re: New in Git: switch and restore

#112

Post by layoutIfNeeded »

leephillips wrote: post #90
layoutIfNeeded wrote: post #46

No thanks, I will keep using checkout.

Me too. The checkout command makes sense and seems consistent to me: check out branches or files. Why do I need two other different commands for this?

Exactly. The way I see it is that “checkout” has two arguments:

- the commit you want to checkout, which defaults to HEAD

- the files you want to checkout, which defaults to everything

Simple as.

Re: New in Git: switch and restore

#113

Post by emodendroket »

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 find the visual ones often harder to use but that's just me. Whatever works works.

Re: New in Git: switch and restore

#114

Post by recursive »

rnestler wrote: post #62
aryamaan wrote: post #40

I picked up git restore with git's suggestion itself. Whenever I do git status, it tells me which files are changed and if I want to go back to their previous states, I can use got restore.

For some time I was pretty annoyed that git was showing the new suggestions, but for some reasons my git autocomplete did not know about them and thus couldn't tab complete. (It was on ArchLinux with zsh using the grml zsh config). After a few month the autocomplete got updated as well and I could actually use the new interface without to much frustration.

I've never seen the auto complete work with anything but file paths. Nor did I know it ever could.

Re: New in Git: switch and restore

#115

Post by recursive »

hsn915 wrote: post #53
thecupisblue wrote: post #38

Earlier quoted context omitted.

Doesn't seem overloaded, seems quite fitting. Checkout a hash or a file from a hash. Switch kinda seems "underloaded" in this way.

Yea it never bothered me and I never understood why people kept complaining about it online. It seemed very superficial complaint. The way you use git is by first understanding its model. If you understand the git model, everything makes sense. If you come to it expecting it to be a tool that magically does what you want, I guess you will be very disappointed.

I don't think magic is part of it. People like me just want it to be consistent.

Re: New in Git: switch and restore

#116

Post by agilob »

intellix wrote: post #83
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 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 not have git-bash installed. I was asked for recommendation of GUI tooling for git and I had absolutely nothing to say, the only I ever used was Kraken and that was in 2014?. When I offered to train and assist everyone with git command training to make everyone more efficient in industry standardised tooling, they told me that's not in the plan. My job was done there without me having to do doing anything, I was free to leave that job!

Re: New in Git: switch and restore

#117

Post by cerved »

quietbritishjim wrote: post #100
oauea wrote: 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.)…

A combination of git diff, git checkout --ours/theirs . && git add and git mergetool works well in my experience

Re: New in Git: switch and restore

#118

Post by cerved »

snarfy wrote: post #105
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…

We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's…

we use it because it's blazing fast, stable and extremely versatile

Re: New in Git: switch and restore

#119

Post by thesuperbigfrog »

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.

Re: New in Git: switch and restore

#120

Post by imiric »

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…

I highly suggest delta[1] for viewing diffs on the command line. It pretty much replicates GitHub's diff rendering, and is quite configurable.

[1]: https://github.com/dandavison/delta

Post reply on HN