New in Git: switch and restore • Hacker News Board

Re: New in Git: switch and restore

#451

Post by indymike » Mon, Aug 02, 2021, 9:46 AM UTC

wpietri wrote: post #401

indymike wrote: post #239

Earlier quoted context omitted.

> "Thanks for pointing that out! I have filed an issue." This means, here's my problem, someone else fix it for me. Since it has not been fixed for YEARS, maybe not the best alternative if you want to get it fixed.

If it truly hasn't been fixed for years, then either the people involved haven't noticed or don't care. If the former, filing an issue is helpful. If not, filing a patch may not get anything fixed either.

It is more likely that "the people involved" are working on other things or just don't share your concern. Filing a ticket can be helpful, but a pull request is usually preferred times 10,000. You are right, it is also possible that a change may mot get merged... In which case you've added the feature so the software is more useful to you anyway. Everyone wins.

Re: New in Git: switch and restore

#452

Post by bserfaty » Mon, Aug 02, 2021, 9:54 AM UTC

_6pvr wrote: post #428

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…

I've always found it interesting that Git gets a pass for its horrible UX by so many devs. The programming community wants to provide too many options for _everything_. If there's a tool you don't like, there are probably 10 other versions that do similar enough things that you can just switch. Devs are harshly critical of tools. And yet, with Git, the response just seems to be "if you don't like it you must just not…

Well, that's why it's called git. Everybody has to get-it.

Re: New in Git: switch and restore

#453

Post by quickthrower2 » Mon, Aug 02, 2021, 9:54 AM UTC

cryptonector wrote: post #403

quickthrower2 wrote: post #384

Earlier quoted context omitted.

Merging rocks! Never had an issue with merging and it’s less work. I’d only rebase if there is a “story” I want to tell in the commit history, that would be otherwise lost. This is rare, probably if someone else did some major refactor or move around

Merging makes life harder for others , and easier for you . Rebasing does the opposite, but has other benefits.

It only makes a difference if everything is fast forwarded onto master. If branches are squash merged in (as is common), keeping those merged in branches up to date via merges or rebasing doesn't make much difference to others.

If you are chucking all your commits onto master - power to you. That's probably a good pattern (I prefer as much historical data as possible to a 'neat' commit history), but I never see it done because usually master is linked to CI and the idea is is every commit to master should be a valid build.

Re: New in Git: switch and restore

#454

Post by laumars » Mon, Aug 02, 2021, 9:56 AM UTC

tehbeard wrote: post #443

laumars wrote: post #375

Earlier quoted context omitted.

What happens when the GP runs into an issue themselves. Do their colleagues help him or return the same cold shoulder? Computers are sufficiently advanced that there will always be blind spots in your team. Sometimes that means working together as a team to figure them out. Which is the kind of behaviour a good manager should encourage and the sort of attitude a good senior engineer should have already learned.

The issue isn't the technical complexity, it's the office politics. If they fix it, do they then become responsible for fixing it in future? Is this now a "responsibility" the "company" (coworkers) expects of them, with no compensation? In addition to their existing responsibilities? I introduced git to the company I'm at (previously on SVN running on an old beige box in the corner). It made collaboration easier. I a…

Again, it shouldn’t be a matter of office politics. If you have a healthy team then everyone will chip in their individual strengths. Yours might be git but someone else might be stronger with Bash, package management, or whatever. Eventually you end up with everyone helping each other. So while you might get interrupted occasionally for git queries, you’d save hours on another issue that someone else helped you with.

There should also be schemes in place to help people level up their own skills. Whether it’s organised training days or an acknowledgment that x number of hours a sprint is spent on personal development (A Cloud Guru or whatever).

If a company doesn’t set up those two pillars then they risk creating toxic teams and that’s ultimately more harmful for productivity than any lost time in a given day helping a peer with version control.

Source: been a hiring manager at several companies. Seen what works and what doesn’t. Ultimately a closer team almost always out performs one where individuals are only looking out for themselves.

Re: New in Git: switch and restore

#455

Post by ivanbakel » Mon, Aug 02, 2021, 9:58 AM UTC

_6pvr wrote: post #428

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…

I've always found it interesting that Git gets a pass for its horrible UX by so many devs. The programming community wants to provide too many options for _everything_. If there's a tool you don't like, there are probably 10 other versions that do similar enough things that you can just switch. Devs are harshly critical of tools. And yet, with Git, the response just seems to be "if you don't like it you must just not…

>And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive?

There are lots of UIs for git - many people on this forum will advocate for using one. My personal experience is that a UI manages to over-simplify the git workflow. It never quite allows you to perform all of the useful tasks you want, unless your use of git is very basic.

In a more general sense, git can also be considered quite conceptually simple; "getting it" is not the real problem most users have. The confusion about what commands do comes from the fact that users learn the tool backwards. No job bothers to teach a junior developer about the DAG and what commits, branches, and refs really are. Instead, they are forced to start with git's large and crufty CLI - so it's no surprise that it's hard to pick up any intuition about what's going on.

And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality.

Re: New in Git: switch and restore

#456

Post by nbjoerg » Mon, Aug 02, 2021, 10:19 AM UTC

sharken wrote: post #335

eloisant wrote: post #306

Earlier quoted context omitted.

No, we use it because it's superior to the competition. It's much better than Subversion that was the standard before git arrived. And it's much better than Mercurial that was competing to become the source control system to replace SVN.

As someone about to migrate from Mercurial to Git i absolutely agree that Git is the superior tool. Pull Requests were never going to happen with Mercurial and it's also not possible to delete a branch without some black magic server-side. And with Git hopefully it will be possible to move to Trunk-based development, although that requires a lot more than just switching to Git.

There are at least two different commercial hosting sites that implement a pull request model. If you want ephemeral branches like in git, hg branches are indeed not the right choice. But that doesn't mean that they don't have their place. Try topic or bookmarks if you want gitish behavior.I have absolutely no clue what you mean with trunk-based development...

Re: New in Git: switch and restore

#457

Post by jhasse » Mon, Aug 02, 2021, 10:32 AM UTC

wpietri wrote: post #170

asimpletune wrote: post #160

Earlier quoted context omitted.

I don’t know why this is getting downvoted. It’s the correct solution and actually a great opportunity to make an easy contribution to open source.

It's not the correct solution because it requires knowledge of the intent of the project leaders, which is not easily available to us. A much better response would be, "Thanks for pointing that out! I have filed an issue." One can't simultaneously through shade for not being community-spirited while expecting other people to do all the work.

> I have filed an issue.

The Git project has no issue tracker though.

Re: New in Git: switch and restore

#458

Post by magpi3 » Mon, Aug 02, 2021, 10:36 AM UTC

indymike wrote: post #203

crazygringo wrote: post #165

Earlier quoted context omitted.

First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help. And second, what exactly mystifies you about what e.g. SourceTree menu commands do? They map clearly and intuitively to CLI commands. If you have "no idea" what it's trying to do then you're not even trying to be helpful. You're just being condescending…

> First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help. Unfortunately, a word needs to exist that stands in for this: "Person, who isn't so different than myself when I started, with little experience who is mistake prone due to the lack of experience, who's mistakes creates disruption and often great expe…

Beginner or junior developer works. Noob has a history of being used in a derogatory sense, so that's how many people read it.

Re: New in Git: switch and restore

#459

Post by magpi3 » Mon, Aug 02, 2021, 10:43 AM UTC

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…

But he didn't write it. He started writing it in bash, and then (because he is Linus Torvalds), some very talented linux hackers jumped in to to help him. Just like with the kernel really. It was a tool written by extremely competent linux hackers for linux hackers, and that's why it is so successful.

Re: New in Git: switch and restore

#460

Post by alkonaut » Mon, Aug 02, 2021, 10:46 AM UTC

eevilspock wrote: post #438

alkonaut wrote: post #422

Earlier quoted context omitted.

How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).

Keep in mind this is your opinion. Unless you've done a poll of users (my comment is getting a lot of upvotes), you have no idea what most people prefer. I can come up with more reasons why -c is better, why consistency in this case is not an issue, and why -b makes sense for checkout, but it's not worth the time debating opinions on a done deal . The only reason I bothered commenting is your comment pretty much call…

I don’t have as much issue with this particular switch as I do with the taped together ball of aggregated mud that is the existing set of git commands. Those are the reason I found this particular one amusing. I would have preferrec consistency over intuitive (or allowing both!) but as you say I have no idea what a majority of users would prefer. I’m pretty sure whoever chose this doesn’t either (another problem with relying on software that can’t pay thousands of dollars for UX testing).

The fundamental problem with this UX is that it (like so many Unix tools) doesn’t draw a hard line between interactive use and scripting use, so making large changes is out of the question since the interactive UX is already scripted in thousands of aliases and CI scripts. That’s a different topic though.