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

181–190 of 550 posts

Re: New in Git: switch and restore

#181

Post by asimpletune »

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.

Submitting a patch would start with filing an issue right? And I assume in that venue the maintainers would clarify their intent. If help were indeed needed then I’m sure the maintainers would be relieved to get some help fixing the documentation but.

In any case, the suggestion of submitting a patch when you notice a problem doesn’t deserve downvotes. That’s not throwing shade, at all.

Re: New in Git: switch and restore

#182

Post by dagw »

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

Isn't that just being incredibly lazy. Surely a reasonably experience person like yourself should be able to read the error message and at least get a rough idea about what the problem is. Then from there explain how you would fix it on the CLI and try to map that onto the GUI. Most Git GUIs map fairly closely to the underlying git model.

Why not just say the truth "I could help you, but it's not my job, so I'm not going to"

Re: New in Git: switch and restore

#183

Post by baq »

emsy wrote: post #80
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 completely agree. It always baffles me how something so simple (yes, simple!) as version control can end up as the abomination that is git. After controlling for popularity, you don’t see nearly as much posts explaining subversion in detail, and subversion being centralized is neither the only nor the biggest reason for that.

Wow, I’d never call version control simple. Actually it’s fiendishly hard. Git makes some simplifications (!) to make the problem more tractable.

Re: New in Git: switch and restore

#184

Post by wpietri »

thecupisblue wrote: post #109
yunohn wrote: post #78

Earlier quoted context omitted.

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”. Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git. The goal of being a programmer is to produce cool things, not to duel with your to…

I don't know git from scratch, never written it or dived into source code itself. Yes, you can write C without understanding poinnters, you can paint without understanding colors and how they mix, draw without knowing difference between 3H and 2B, use a drill without knowing which type of head is for what. But try doing it long term and you either gotta learn those things or your output will be limited and clear expr…

C is a great example here. If you write a lot of C, you really have to understand pointers very well. And quite a lot else. That makes it a bad tool for many purposes, so most developers do not use it, and fewer use it every year. It's just a bad tool for modern purposes.

The same applies to the git CLI. And really, to git. The right tool for a small group C-using kernel developers 15 years ago may not be the right tool for different people doing different things today. Let's hope it goes the way of C.

Re: New in Git: switch and restore

#185

Post by jbverschoor »

jamesmontalvo3 wrote: post #147
akamoonknight wrote: post #104

Earlier quoted context omitted.

I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.

If I need to visualize the network of commits I use this alias in .gitconfig: network = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

I'd rather use a "visual tool" to visualize

Re: New in Git: switch and restore

#187

Post by laumars »

crazygringo wrote: post #165
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

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…

I get you disagree with the GPs post but “noob” isn’t offensive. What’s offensive is their lack of support for colleagues (which reads like a potential issue with their own ego: where they didnt want to be shown up in an unfamiliar UI). But their post reads exactly the same if you substituted “noob” for “newbie”, “junior”, “inexperience” etc.

What we need to do is get passed this ridiculous mindset some have that not knowing something is a bad thing. We all have to start off somewhere and “noob” is just a common term for describing that. Case in point: I’ll readily post “noob question guys, how do I…?” on Slack to give context that I’m asking a potentially basic question and basically don’t really know what I’m doing. For reference, I am the most senior on my team and yet I have zero issue highlighting stuff I don’t know when asking for help. And that’s exactly the way it should be.

There’s no shame in being new at something. What there should be is shame in wanting to mock newbies and shaming and those who don’t offer up their help to others. Being a noob should be celebrated as someone new joining the team rather than added to our dictionary of inappropriate terms.

Re: New in Git: switch and restore

#188

Post by wpietri »

asimpletune wrote: post #181
wpietri wrote: post #170

Earlier quoted context omitted.

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.

Submitting a patch would start with filing an issue right? And I assume in that venue the maintainers would clarify their intent. If help were indeed needed then I’m sure the maintainers would be relieved to get some help fixing the documentation but. In any case, the suggestion of submitting a patch when you notice a problem doesn’t deserve downvotes. That’s not throwing shade, at all.

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.

Re: New in Git: switch and restore

#189

Post by azundo »

gallier2 wrote: post #124
akamoonknight wrote: post #104

Earlier quoted context omitted.

I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.

and the ultimate option for git lg is --reflog. Seeing all branches, even the old ones that do not exist anymore is a eye opening event in discovering the true nature of git: it never changes a commit, ever.

While reflog is amazing, the "ever" in your statement is not true, `git gc` will prune your reflog: https://git-scm.com/docs/git-gc

Most of the time this doesn't matter in practice but you should be aware that unreachable refs don't stay around forever.

Re: New in Git: switch and restore

#190

Post by Shorel »

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…

A couple of easily added aliases to .gitconfig and my CLI can do everything your GUI can do, in a portable way, and much easier and faster IMO.

Nothing to learn or even forget, either, as the CLI is actually the easier part of the job.

So, you do you, nothing wrong with that, but the CLI is here to stay.

Post reply on HN