Live data from Hacker News

New in Git: switch and restore

banterly.net

411–420 of 550 posts

Re: New in Git: switch and restore

#411

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.

I don't like Sublime Merge that much. Probably because I tried GitKraken first and loved it. It helped me understand stash and rebase better than the command line ever did. At some point they decided to not allow gratis use on private personal repos so I switched to VSCode with the Git Graph extension which gives me most of what I liked from GitKraken.

Re: New in Git: switch and restore

#413
post #178

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".

Add `-p` (`--patch`) and then pick from the diff prompt what parts you want to restore. You can also use this flag with commit.

Re: New in Git: switch and restore

#414
post #353

Earlier quoted context omitted.

>What was their justification for being like that? The more tools people are allowed to install and use, the less standardised software development. Meanwhile we didn't even have common source code formatting pattern and single Java class could be formatted with tabs, 2 spaces and 4 spaces.

Not necessarily. On my team at work we have people using Sublime Text, VS Code and vim, but all 3 (+ our CI) plug into ESLint and TypeScript for ensuring style coherence.

Why don't you encourage people to use their linters of choice? Why expect everyone to use ESLint?

Re: New in Git: switch and restore

#415

Earlier quoted context omitted.

Not necessarily. On my team at work we have people using Sublime Text, VS Code and vim, but all 3 (+ our CI) plug into ESLint and TypeScript for ensuring style coherence.

Why don't you encourage people to use their linters of choice? Why expect everyone to use ESLint?

If you want style coherence, the same linter with the same options makes sense. “Use your preferred linter” won't produce style coherence.

Re: New in Git: switch and restore

#416
post #94
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…

Don't use it blindly. Learn it enough that you understand those mystical incantations and aren't summoning Cthulhu by accident, only on purpose

Don't cookbook it, understand what the thing you're typing means. Don't use a GUI to abstract it away, be familiar with the CLI and what it's doing. Don't default to rm-rf when you get stuck, check git reflog and see if you can unfuck yourself first. Ask someone who doesn't have your problems how they're using it - it's possible you're "holding it wrong" in some obvious way, but in a way that masks the true problem that's biting you.

Some of my coworkers regularly have problems with git - I don't, and some other coworkers also don't. We all use roughly the same workflow, it's the people familiar with "what does pull --rebase really do?" that don't get into trouble and/or can get themselves back out of trouble, and the ones who always type the same command regardless of the situation that have problems.

Learn your tools, inside and out.

Re: New in Git: switch and restore

#417

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

i think they had a design meeting where they said "lets add some new commands to make git easier for newbies".

carrying over flags whose abbreviated forms don't make any sense in the new context doesn't make anything easier for anybody. if you want to keep using the commands you have memorized, you can do that - just don't use switch or restore. the new commands are different, that's the point.

Re: New in Git: switch and restore

#418

Earlier quoted context omitted.

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

> I have trouble imagining you can't figure that out on your own.

I'm not being coy, as if I really know what you think, but I'm asking anyway just to be frustrating. I mean, I have an idea, but I also didn't want to make assumptions about your intent, when it's just as easy to ask you to elaborate. After all, it's your point that it was incorrect, so I just wanted to know why.

Any way, you said there are "legitimate ways to suggest submitting a patch, but this isn't one" (I'm paraphrasing). To me that didn't really make sense, because that implies one of the wrong ways to suggest submitting a patch is to suggest submitting a patch.

> 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

In my mind, it seems like the effect that it would have on them is to suggest to them to submit a patch. Alternatively, it might also have no effect, because they might not care enough to do anything about it, or just be busy, which is also ok. They don't have to listen to any advice, and it was given in good faith, without malice.

I can also imagine a situation where it is technically possible for someone to attribute all sort of weird malice to "so submit a patch" that wasn't actually there. After all, people can feel however they want. However, in my opinion it's quite rude to assume about someone without knowing them that they're such a fragile creature as to invent malcontent where there is, in my eyes, obviously none.

So going back to when I said "I have an idea", I meant that yeah I can imagine, after this back and fourth, that maybe you would assume something like this about someone else - that they can't hear "so submit a patch" without taking it en every wrong way possible - but I didn't want to make that assumption without at least giving you the opportunity to explain yourself.

Ok, on to exploring other ways to encourage them to submit a patch. You could say, "Do you know you can submit a patch?", "Feel free to submit a patch", "This looks like a documentation bug, would you submit a patch?". All of these also seem fine to me.

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

What I don't like about this, personally, is that you're convinced their suggestion wasn't sincere, as if there has to be an ulterior motive. As if believing that a programmer on a startup forum is capable of fixing a documentation bug is so crazy, there can be no other explanation than really they were trying to humiliate the other person.

Any way, I do believe that you're trying to be helpful and it's not really that big of a deal so no worries. Hope you can believe me when I say I'm being sincere as well. Basically, a lot of people have different ways of encouraging each other, and there are a lot of different styles of encouragement that people appreciate. It doesn't mean that one you don't agree with is wrong. When I read "so submit a patch", my mind didn't immediately go negative, and I hope the recipient of that didn't either.

Re: New in Git: switch and restore

#419

Earlier quoted context omitted.

Indeed, and it should be clear that "noob" is intentionally/cleverly spelled like "boob" in the sense of "idiot". That's the whole point of the word -- that's the joke. Now it's fine to joke around and call yourself a noob, that's just self-deprecating. But if you're talking about other people and don't want to inadvertently offend, stick to "newbie" in speech or "newbie/newb" in writing, which have a connotation ent…

I've been using the term noob for decades. Reading your comment is the first time I've ever seen anyone compare it with boob . There is a big world out there, with lots of different people using words to mean things.

Well it's certainly widely established that "noob" is more derogatory [1] [2]. Take that for what you will when you choose to use it.

[1] https://www.etymonline.com/word/noob

[2] https://en.wikipedia.org/wiki/Newbie#Connotations_of_variant...

Re: New in Git: switch and restore

#420
One of the most common footgun mistakes I see in Git is people checking out a detached head state without knowing it, doing some work, then trying to push and immediately going to hell. I like that switch prevents this behavior by default. Also all git installations should come with a default shell prompt update so that it will show you immediately that you've gone into a detached head instead of a branch name. All git onboarding tutorials should include that instruction right after installing git.
Post reply on HN