New in Git: switch and restore • Hacker News Board

Re: New in Git: switch and restore

#341

Post by kangalioo » Sun, Aug 01, 2021, 7:27 PM UTC

b3morales wrote: post #301

alisonkisk wrote: post #254

Earlier quoted context omitted.

Newbie is a nicer word.

Why?

"Noob" has a negative connotation.

https://www.urbandictionary.com/define.php?term=Noob

> Contrary to the belief of many, a noob/n00b and a newbie/newb are not the same thing. Newbs are those who are new to some task* and are very beginner at it, possibly a little overconfident about it, but they are willing to learn and fix their errors to move out of that stage. n00bs, on the other hand, know little and have no will to learn any more. They expect people to do the work for them and then expect to get praised about it

The specifics of the definition probably vary depending on who you ask but that's roughly it.

Re: New in Git: switch and restore

#342

Post by derac » Sun, Aug 01, 2021, 7:31 PM UTC

b3morales wrote: post #283

ketzu wrote: post #220

Earlier quoted context omitted.

My personal experience around noob is covered by the ones I found on ~~most~~ edit: the most high search-ranked online explanations: Mostly negatively conotated, deregatory version of newbie. Often associated with people not sufficiently able to learn or at least not learning on their own. Examples: * https://en.wiktionary.org/wiki/noob * https://www.etymonline.com/word/noob Examples not containing the negative conno…

I often see people self-describe as noobs when asking technical questions, for example in programming Reddits. I couldn't say that I understand the reason for it, though.

Saying you're a novice when asking for help can be useful. People will use less jargon and point to more accessible resources, etc.

Re: New in Git: switch and restore

#343

Post by poidos » Sun, Aug 01, 2021, 7:32 PM UTC

User23 wrote: post #223

quietbritishjim wrote: post #100

Earlier quoted context omitted.

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

Magit[1] is also excellent. And like all good git tools it exposes a log of what it did. Unfortunately it doesn't work so great with megarepos, but I understand that's being worked on. One area where this tooling is vastly superior to the command line is adding hunks instead of files to a commit, making it much easier to have a sensible history while allowing programming in a more natural style. [1] https://magit.vc/

+100 for Magit. My favorite feature is rebasing directly on logs.

Re: New in Git: switch and restore

#344

Post by LambdaComplex » Sun, Aug 01, 2021, 7:34 PM UTC

agilob wrote: post #156

nicoburns wrote: post #128

Earlier quoted context omitted.

Sublime merge would have been a good suggestion in this scenario. It's UI uses standard git terminology and concepts, so you'd have been sneakily trainig them in the command line whilst they used the UI!

It was in a very old fashion and regulated working environment where developers and testers aren't allowed to install whatever they want. Software installers can be whitelisted after a review is done. It included things like: licence OSS vs enterprise, support, community, or even more banal things like stars on github. Adding new software to a list could take literally months - like in case of git GUI client. Sublime…

What was their justification for being like that?

Sometimes I read these things and end up saying to myself "Wow, that company just literally hates being productive"

Re: New in Git: switch and restore

#345

Post by TameAntelope » Sun, Aug 01, 2021, 7:44 PM UTC

yjftsjthsd-h wrote: post #101

lisper wrote: post #94

Earlier quoted context omitted.

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

> What's the alternative, that they should learn to use it improperly? Yes. Or at least, avoid learning anything if they can help it, treating it as a black box that can never be understood. "Learn got properly" just means "actually make an effort to learn the tool rather that clinging to learned helplessness".

A viable alternative my coworkers seem to have adopted is, “Execute the git commands blindly as provided by me and get upset with git when something doesn’t work right.”

Re: New in Git: switch and restore

#346

Post by brundolf » Sun, Aug 01, 2021, 7:45 PM UTC

As with all successful software that's been around for a decade or two, git is too darn complicated.

To adapt the adage about democracy: git is the worst VCS, except for all the other ones.

Re: New in Git: switch and restore

#347

Post by stormbrew » Sun, Aug 01, 2021, 7:48 PM UTC

crummy wrote: post #340

stormbrew wrote: post #332

Earlier quoted context omitted.

I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it. Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally impor…

I don't understand how "using a GUI to drive this tool" instead of "using a CLI to drive this tool" means someone doesn't understand version control, doesn't care about how their code interacts with their team, or doesn't know how the tool works.

I don't understand how I'm supposed to reply to this given that it claims I said something I didn't even come close to saying and has nothing to do with what either me or the GP post were replying to.

If you want to try again, the central thesis of my post was:

"Using git (or some kind of version control) is, in fact, your job."

With a digression that amounts to:

"The disdain OP's post shows towards people who take the time to understand the tools fundamental to performing their job is extremely unappealing to me in a coworker" (ie. the "they should get a job managing a git repo or something" part)

Re: New in Git: switch and restore

#348

Post by einherjae » Sun, Aug 01, 2021, 7:48 PM UTC

MarkSweep wrote: post #293

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

What about staging lines to the index? I tried ‘git add -i’, but it feels pretty clunky compared to selecting some lines with a mouse in git-gui.

git add -p

Re: New in Git: switch and restore

#349

Post by Nursie » Sun, Aug 01, 2021, 7:53 PM UTC

jen20 wrote: post #148

Nursie wrote: post #121

Earlier quoted context omitted.

How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress? I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system. The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source cont…

They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup.…

You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later.

I’m fact I’ve found that far more useful than a well curated history.

Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.

Re: New in Git: switch and restore

#350

Post by kevincox » Sun, Aug 01, 2021, 7:54 PM UTC

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

I am very happy with delta.

I slightly tweaked the default config and it is great.

    [core]
     pager = delta
    [interactive]
     diffFilter = delta --color-only
    [delta]
     features = navigate
     hunk-header-style = omit
     line-numbers = true
     line-numbers-left-format = "{nm:>3} "
     line-numbers-right-format = "{np:>3} "
     max-line-length = 0