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

271–280 of 550 posts

Re: New in Git: switch and restore

#271

Post by 0xEFF »

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 recently tried to help someone onboard into a cloud project that requires git tunneling due to security policies.

While they had experience with their IDE of choice and git, they were ultimately unable to push any changes.

Re: New in Git: switch and restore

#272

Post by rattray »

tkuraku wrote: post #145

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.

For those wondering this is a separate application from Sublime Text, built by the same folks, and with the same free evaluation and $99 lifetime license (not sure how "required" it is).

I haven't felt a need for a git gui but I might give this a try anyhow.

Re: New in Git: switch and restore

#273

Post by wizzwizz4 »

foepys wrote: post #212
wizzwizz4 wrote: post #209

Earlier quoted context omitted.

Version control isn't a tool I use. It's the filesystem I store my files in.

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

All things I know are possible. I understand Git's architecture, just like I know what an inode is. I could re-implement my own (bad) version control system, if I wanted to, just like I could make my own (bad) filesystem.

But that doesn't mean I need to have memorised the CLI invocations. There's a button in Git GUI for all the things I need to do (including the things you've listed), and in the rare case where I need to do something else (e.g. submodules), I can look it up, just as I do in the rare case where I need to make a symbolic link.

Re: New in Git: switch and restore

#274

Post by wizzwizz4 »

PaulDavisThe1st wrote: post #251
alisonkisk wrote: post #243

Earlier quoted context omitted.

I resolve conflicts in GUI every week. I find the location of a bug by running tests and looking at the code.

git bisect will optimize the number of tests you have to run, and will reduce the amount of code you have to look at it to the minimum (in general).

Assuming a binary search over version history is a valid way of finding the bug. If you have a better idea of the probability distribution (e.g. it might've started being buggy any time in the past year, but I'm fairly sure it happened about nine months ago when the formatting of the report broke a bit) you can do a better job manually than `git bisect` – and if the bug is actually multiple bugs, or other things changed that affected the bug's presence or absence (making it appear or disappear in non-trivial patterns between versions), `git bisect` will mislead you.

`git bisect` is pretty cool, but “knowing your tools” isn't the same thing as “memorising the man pages”.

Re: New in Git: switch and restore

#275

Post by escape_goat »

PaulDavisThe1st wrote: post #263
escape_goat wrote: post #255

Earlier quoted context omitted.

It would be perfectly reasonable for someone to just say "no, I'm not going to imagine my job designing software as analogous to cabinetry," because argument from analogy shifts some of the burden of proof to the analogy itself, and the analogy must be defensible. In this case, you're drawing an equivalence between OP's 100 complex things and 100 cabinet components that must be assembled, yet also drawing an equivale…

> A domain expert is telling you that version control is a peripheral concern in their trade 1) I have no way of knowing if they're a domain expert. 2) With 35 years of software development under my belt, and a half dozen version control systems too, I'd consider myself likely to be as much of a domain expert as the OP, and I'm saying the opposite. 3) I am not as master woodworker. I have built cabinets and many othe…

This is an excellent reply, more interesting than my comment, and I certainly cannot gainsay you. However, '100' might as well be 'n'. Your reply suggests that there is a struggle to maintain contextual awareness of 'n'. In this model, for everyone, there will be an n+1, a necessary factor where the diminishing returns of mastery do not justify the cognitive load. I do not think the heart of your dispute truly lies so much his model of peripheral necessities as with his ranking of git as an n+1 tool.

Re: New in Git: switch and restore

#276

Post by wizzwizz4 »

ithkuil wrote: post #257
foepys wrote: post #212

Earlier quoted context omitted.

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

I interpreted what GP said as " the version control system is the place I store my files, so it's not just a tool, but it's an essential and necessary environment, the space where I organize my stuff"

That's more what I was going for. It's also part of the background, as opposed to something I deliberately interact with, so I don't use it like a tool in my day-to-day.

Re: New in Git: switch and restore

#277

Post by PragmaticPulp »

PaulDavisThe1st wrote: post #260
PragmaticPulp wrote: post #249

Earlier quoted context omitted.

> What you should not do, IMO, is to say "Oh, I have a CNC system, but I never interact with it directly, I let CNC-Foo on my computer control it whenever I need to do anything". I have experience with CNC machines, and I would still not recommend that anyone try to control their CNC machine by typing in G-Code directly. Understanding G-code can be helpful, but you really need to learn to use the higher-level tools p…

1) I don't think it ever makes much sense to have a concept such as "HN is really strange on ...". This place is a collection of thousands of individuals, and you're going to see a wide range of opinions, many of them contradictory. Since not everyone comments on every article, you'll see patterns that are not reflections of a single position held by any particular person. If you see contradictions in things that I'v…

> 1) I don't think it ever makes much sense to have a concept such as "HN is really strange on ...".

I enjoy HN, but I've also been here long enough to accept that HN is an echo chamber. Yes, we have downvotes and a variety of opinions, but the reality is that if you come into certain threads expressing certain unpopular opinions you're going to get hit with a wave of downvotes. Eventually you learn to just stop posting those opinions, which results in an echo chamber effect.

No social media site is free of echo chamber effects. HN is not an exception.

> I haven't used a CNC system, but...

Friendly suggestion: If you're not familiar with how something works, maybe it's not the best subject for an analogy?

Re: New in Git: switch and restore

#278

Post by tester756 »

thecupisblue wrote: post #54
phist_mcgee wrote: post #42

Earlier quoted context omitted.

I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems. Unfortunately due to time constraints, interest levels, and simply ease people go top down. They need to switch branch, so they will follow the least effort principle and use a UI. Barely understanding many fundamental tools is common thes…

> I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems Actually, I'm trying to look at it more from a "shallow sea" perspective - you have a problem and are given a tool to solve it. But do you not dive in just a bit to see "hey what is this tool" after you solve the problem? Or after using i…

I use GUI because it's infinitely times easier for me to check what changes I've done and to rethink them e.g trying to spot a stupid bug

>With that mentality, what do you ever learn?

>Where is the joy in that? Where is the growth?

>Are you always in a rush to deliver software without a moment to think?

There's nothing sexy about learning git commands for me

I'd rather spend that time on actual computer science fundamentals or even reading stuff like HTTP RFC than learning git quirks

Re: New in Git: switch and restore

#279

Post by nerfbatplz »

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…

Except for 99% of all git day to day tasks are done with like 7 commands.

Git commit

Git checkout

Git merge

Git pull

Git push

Git rebase

Git stash

I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

Re: New in Git: switch and restore

#280

Post by dfabulich »

Lordarminius wrote: post #228

As a helpful aside, in my experience, there are only about a dozen or so Git commands you need to do ninety percent of your work. You don't need to become a git zen master right away. 1. git init: to start a new repository 2. git status: checks your current state 3. git add -A: To begin tracking files 4. git commit -am: Commit all changes in the working directory with a message added on 5. git switch -c [branch name]…

Odd that you put switch on this list but not restore. Undoing changes is pretty important.
Post reply on HN