Live data from Hacker News

New in Git: switch and restore

banterly.net

281–290 of 550 posts

Re: New in Git: switch and restore

#281

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

This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that? Even if it’s exceptionally wonky, I have absolutely no problem introducing git to new devs, as long as it’s alongside a graphical representation (sourcetree or some ide-extension), and as…

> This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that?

always did give me a chuckle how it took off the way it did for projects that don't come even remotely close to the scalability (like tree sizes) it provides.

the facts that it's free, fast, reliable, good for offline operation and can be used for huge and tiny projects alike are nice though. just never expected to see the day when web designers would become religious about using it.

Re: New in Git: switch and restore

#282

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 don’t completely agree.

> My job isn’t to use git, it’s to write specialist software.

I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!).

So, as I think most people would agree: you certainly don’t need to understand the obscure corners of your programming language, but you should have a solid understanding of the fundamentals and a decent overview of the rest.

In the case of source control, and git in particular, IMHO you should have a decent fundamental understanding (which isn’t even particularly complex at a conceptual level) so even if you don’t remember the command for ‘X’ , you’ll know to look for it when you do need it.

Given how you started your comment, perhaps you don’t even agree with implication of the sentence I quoted.

(edit: added IMHO)

Re: New in Git: switch and restore

#283
post #220

Earlier quoted context omitted.

Eh, that term seems to have fallen out of favor compared to when I was a growing up but I don't think it necessarily has a negative connotation. I remember being in programming and software related IRCs at 10-11 years old having no earthly clue what in the fuck I was doing, asking adults questions and getting called a "noob". Well, yeah, it was true. (I also made damn sure they had no idea I was a child.) They could…

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.

Re: New in Git: switch and restore

#284

Earlier quoted context omitted.

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

if you are confident that it happened about nine months ago, then just start the bisect bounded by age-appropriate commits. just a case of knowing your tools ;)

yes, if the bug is a complex interaction of several different code changes, and comes and goes, then a binary search will not find it. however, it may be the fastest way to realize that it is this sort of bug. recognizing patterns in what happens when you use git bisect is another aspect of knowing your tools, and in this case, will help you move more rapidly toward a more appropriate approach.

Re: New in Git: switch and restore

#285

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

Specially when the ide doesn't use standard names and/or introduces new terms. Visual/ide tools to use git are welcome and I use them occasionally. But the cli should be the common denominator.

Re: New in Git: switch and restore

#286

Earlier quoted context omitted.

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

"Haven't used" isn't the same as "have never been in a shop with a CNC system installed, never worked around people using them, and have no close friends who use them regularly".

As for the echo chamber, you won't be suprised that I disagree with you on this point.

Re: New in Git: switch and restore

#287

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…

Just as a data point, I unselfconsciously describe myself as a noob (or more likely n00b) when I'm inexperienced with something, and still prone to making embarrassing mistakes because I don't know what I'm doing.

Re: New in Git: switch and restore

#288

Earlier quoted context omitted.

You assume that the creator of one of the.. if not the largest open source projects on the planet might not understand the issue at hand better than literally anyone? That seems arrogant. I imagine more thought & care went into git than you can fathom.

Isn't that the "appeal to authority" fallacy? Mercurial demonstrates that you can have a VCS with less painful and frequent gotchas and certainly the grottiness of the git submodule mechanics, for example, doesn't show as much thought and care as one would hope.

How does Mercurial show it? I always found it very confusing to use all the times I tried it so I would need some context to understand your comment.

Re: New in Git: switch and restore

#289
post #138

Earlier quoted context omitted.

> Figuring out what "properly" means is the whole problem with git. I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think…

See my earlier comment here: https://news.ycombinator.com/item?id=27580478

Regarding your first point (and I think some of the commenters in that thread also address this already) is that as long you don't have uncommitted changes, you're safe. You're right that a lot of git-commands mess with uncommitted changes in hard-to-recoverable ways, but once changes are committed, there's almost no way to mess anything up, you can always go back to the previous state (git reflog telling you which commit that was).

Regarding the second point - if you have a rebase-based work-flow, you will encounter this problem less often (or not at all).

For your third point - what helped me a lot is to actively distinguish between commits and the working tree, and making myself aware that branches really are just "pointers" to commits (obviously, but somehow, actively thinking about it made the intent of git commands a lot easier to understand). Also, most git commands are just combinations of other commands. git reset is just moving the pointer (--soft without touching the working tree, --hard will do so), rebase is essentially a hard-reset with consecutive cherry-picks afterwards, and so on.

Also, an eye opener for me personally has been that e.g. an interactive rebase with squash towards a branch that is strictly ahead of you except for the commits you want to rebase is essentially just a "git reset --soft ", and then recommitting everything with a fancy commit-message. This and similar mental gymnastics with git-commands has helped me a lot; most of them really are quite sane (except for all those crazy options), "git checkout" is really the odd-one-out of the bunch (and "git pull" a combination of things that should never have been combined in the first place).

Re: New in Git: switch and restore

#290

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…

Having been through two Perforce -> git transitions of medium sized repos with a few dozen people contributing and being the person with the most git knowledge in the group to be called in when people new to git mess things up: these GUI git clients are ok if you know what you are doing and what the consequences of checking various checkboxes are. They are not conducive to people learning how the tool git works and how to use it to solve real world problems. The command line is a great way to learn git and then fundamental understanding can be used to reverse engineer what GUIs do under the hood.
Post reply on HN