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

41–50 of 550 posts

Re: New in Git: switch and restore

#41

Post by dilap »

thecupisblue wrote: post #38
hsn915 wrote: post #18

I knew about `git switch` but this is the first time I hear about `git restore`. It also never occurred to me that the checkout command was overloaded in that particular way.

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

It's definitely unintuitive for newcomers.

And I think arguably modifying working-directory files vs. modifying .git/HEAD are distinct things (though at this point I also find using checkout for everything to be pretty intuitive).

Re: New in Git: switch and restore

#42

Post by phist_mcgee »

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…

I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems. Unfortunately due to time constraints, interest levels, and simply ease people go top down. They need to switch branch, so they will follow the least effort principle and use a UI. Barely understanding many fundamental tools is common these days for devs, and I honestly think that it's a sign that our field has grown massively in terms of the tools we need to use, the processes we use to deploy, and the products we use to develop. I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs?

It's hard to see the gaps someone else has, and wonder why they can't know what you know, but they may have some deep knowledge in a domain you are only superficially knowledgable in.

I agree we need to nail the basics, but this isn't 2002 anymore, and we don't ship Gold CDs to customers by running a build command on a single PC in the office. Our jobs are so much more complex and multi-faceted, and the oldbeard assumption that things are 'bare essentials' is eroded by the pragmatic realisation that we only have so many hours in the day.

Re: New in Git: switch and restore

#43

Post by tkfu »

This reminds me of the old xkcd [1] about how standards proliferate...

Situation: Git has 137 difficult and unintuitive subcommands [2], and new users can't keep straight which ones they should use.

"Oh man, that's awful, let's add new subcommands that are clear, and do just one thing well!"

Soon: Situation: Git's CLI has 138 difficult and unintuitive subcommands.

[1] https://xkcd.com/927/>

[2] Yup, seriously, as of 2.32. I checked.

Re: New in Git: switch and restore

#44

Post by papaf »

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…

How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning.

Its probably a rhetorical question but I think its worth answering anyway.

Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago.

If you are a new developer thrown into your first real project and Intellij handles git for you so that you can concentrate on being productive then learning command line git takes a back seat.

I see this in many aspects of programming. One thing I am struggling with currently, is that JHipster generates applications in a user friendly way. JHipster is highly productive and seems like the future of programming BUT it means that there will be a generation of programmers that do not understand the MB of Spring Java code that is casually puked out by the code generator.

Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity.

Re: New in Git: switch and restore

#45

Post by Freak_NL »

yakubin wrote: post #32
Freak_NL wrote: post #28

Earlier quoted context omitted.

How do you end up with that many branches? It sounds like you keep every feature branch around forever. Keeping one around for a few months I get (although personally the sooner they're gone after rebasing or cherry-picking them the better), but this sounds like a full on history of every branch ever.

If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something. (Every non-official build is made from a separate branch.)

Deployed versions that need to be referred to later usually get git tagged, but those are not that much different from branches of course (they'll both show up in autocomplete as a committish object). But even then; tens of thousands of tags/branches? At that point it might be worth considering simply baking in the git commit hash into the build artefact for future reference instead of tagging every CI build with a branch/tag.

Re: New in Git: switch and restore

#48

Post by yakubin »

Freak_NL wrote: post #45
yakubin wrote: post #32

Earlier quoted context omitted.

If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something. (Every non-official build is made from a separate branch.)

Deployed versions that need to be referred to later usually get git tagged, but those are not that much different from branches of course (they'll both show up in autocomplete as a committish object). But even then; tens of thousands of tags/branches? At that point it might be worth considering simply baking in the git commit hash into the build artefact for future reference instead of tagging every CI build with a b…

When I say "non-official", I say that it has some commits that aren't on the main branch. You need to push them somewhere, or else they're going to be lost.

Re: New in Git: switch and restore

#49

Post by hkopp »

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 git cdiff.

Other than that, I recommend that people learn to use git properly. In my work, I often have problems with people overwriting their commits and trying to handle merge requests of commits where one commit message is "did some updates" and the other commit is "some fixes". Getting to know git for an hour, may have prevented both issues. But I am biased, since I use git since my bachelor thesis.

Re: New in Git: switch and restore

#50

Post by 5e92cb50239222b »

tkfu wrote: post #43

This reminds me of the old xkcd [1] about how standards proliferate... Situation: Git has 137 difficult and unintuitive subcommands [2], and new users can't keep straight which ones they should use. "Oh man, that's awful, let's add new subcommands that are clear, and do just one thing well!" Soon: Situation: Git's CLI has 138 difficult and unintuitive subcommands. [1] https://xkcd.com/927/ > [2] Yup, seriously, as of…

Most of those are plumbing. They're only needed if you're building tools on top of git (integration with IDEs or custom GUI, for example), or doing very advanced scripting/broken repository repair.
Post reply on HN