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

391–400 of 550 posts

Re: New in Git: switch and restore

#391

Post by Aeolun »

politician wrote: post #310
voakbasda wrote: post #136

Earlier quoted context omitted.

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…

We ask candidates the most ridiculous algorithm and data structure design questions when we should be asking them to describe the git data structures. Let’s fix interviews and kill two birds with one stone.

I do actually. If someone can describe to me what the (mechanical) difference is between a merge and rebase they’re likely to be better :P

Re: New in Git: switch and restore

#392

Post by Aeolun »

jbluepolarbear wrote: post #157
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 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.

Oh, I’ll figure out the problem alright. One git status on the command line aught to tell me what it is.

Re: New in Git: switch and restore

#393

Post by sossles »

rwallace wrote: post #388
erikpukinskis wrote: post #305

Earlier quoted context omitted.

I flagged this because this is extremely dangerous advice. DO NOT use gloves with a table saw, jointer, etc There are exceptions, but if you want a simple rule: DO NOT use gloves with power tools It is extremely dangerous. You can take an injury that would've been a nick on the finger and turn it into a lost hand.

Now I'm curious: why? Not that I don't believe you, but I'm wondering what is the reason? It's not intuitively clear why gloves would make it more dangerous, even knowing that it is.

If a glove comes into contact with a spinning blade, there is a good chance it will pull the rest of the glove, and the hand within it, right into the path of the blade.

Re: New in Git: switch and restore

#394

Post by mattnewton »

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…

I disagree, the point is to get code written that solves problems, and the tools are a means to that end and not an end in of themselves. Our tools should make that task easier and more accessible to more people.

Re: New in Git: switch and restore

#395

Post by Liskni_si »

imiric wrote: post #120
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

There's also diff-highlight[1] which is shipped with git itself and does almost the same thing, just possibly isn't as polished.

[1]: https://github.com/git/git/tree/master/contrib/diff-highligh...

Re: New in Git: switch and restore

#396

Post by Phrodo_00 »

dvlsg wrote: post #241
crazygringo wrote: post #172

Earlier quoted context omitted.

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…

Yeah, viewing a changeset and staging only some files or just parts of files is really important to my workflow. Sometimes I leave myself comments or skip tests locally and I have no intention of committing those changes. Using a tool like sourcetree to review, add, and commit only the lines I want is very helpful and saves me time. I do use the command line for everything else, though. Well except interactive rebasi…

This is also part of my workflow, that I use git commit -p instead. Seems weird to only use a tool for that part when git's included workflow is perfectly capable

Re: New in Git: switch and restore

#397

Post by wpietri »

thecupisblue wrote: post #253
wpietri wrote: post #177

Earlier quoted context omitted.

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…

>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. How should git adapt? Can you get a simpler model than this? Is really a basic structure like a tree so complicated millions of developers are having a hard time with it? Nobody is advocating for "dont use new stuff, old is betteer". Nobody is adv…

One way it could adapt is by doing exactly what this article is talking about: Giving commands for common operations where name and behavior matches user intent.

That you can't tell the difference between "let's make software more usable" and "nobody should learn anything ever again and just soften into blobs of undifferentiated protoplasm" seems like a you problem.

Re: New in Git: switch and restore

#398

Post by ReFruity »

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

That is true, but I think IntelliJ provides you with the list of commands it executed to get there.

Re: New in Git: switch and restore

#399

Post by wpietri »

asimpletune wrote: post #191
wpietri wrote: post #188

Earlier quoted context omitted.

There are ways to suggest submitting a patch that don't come across as dismissive, as a way to shut down a legitimate complaint. But this wasn't one of them.

Ok, and why is that?

I have trouble imagining you can't figure that out on your own. If that's really the case, then take a little time and explain exactly what impact you think that comment would have had on the person they were replying to. Then explore some other ways to actually encourage submitting a patch. Write a couple of them out.

If you do that work, I'm glad to try to help you see where their approach falls short in terms of sincerely encouraging contribution.

Re: New in Git: switch and restore

#400

Post by ReFruity »

alkonaut wrote: post #369

> with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch > You can do the same with the new one, but the flag is -c: git switch -c new_branch It's like they had a design meeting where they discussed this and said "so I propose switch -b newbranch to create and switch to a new branch" and the objection was "nah that would make it consistent with check…

Well, maybe it indicates specifically that they had no meeting :)
Post reply on HN