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

381–390 of 550 posts

Re: New in Git: switch and restore

#381

Post by smusamashah »

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…

If you understand how git works, its data structure essentially, then its far easier to do anything with IDE/GUI instead of CLI. They are more intuitive and shorten the work and less prone to mistakes.

Re: New in Git: switch and restore

#382

Post by OJFord »

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 don't use git CLI so much any more] because I make less mistakes seeing the tree visually all the time.

I look at the tree visually so frequently it must be my most common command. In the CLI.

    log --graph --decorate --pretty=oneline --abbrev-commit
And then optionally adding whatever else, `--all` most frequently. (Obviously not writing it all out every time - with git config aliases, and actually `gitl` as a shell alias for that even. That's probably up there in my top.. 5? shell commands.)

GUIs work too of course. Just pointing out you don't have to abandon the CLI for a tree. There's fancier third-party tools than native git log that are still CLI even.

Re: New in Git: switch and restore

#383

Post by quickthrower2 »

samatman wrote: post #295
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]…

I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file! I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit. I do run `git diff` first to see what I've changed, and if the diff has u…

I’m interested in how many people double check their changes before committing as I’ve done this since the days of sourcesafe, and a decent number of bugs I’ve seen are people just not checking what they committed (some stray change got in that they never intended)

Re: New in Git: switch and restore

#384

Post by quickthrower2 »

cryptonector wrote: post #372
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]…

You're missing out. You need rebase and cherry-pick. Merging sucks.

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

Re: New in Git: switch and restore

#385

Post by Salgat »

Dayshine wrote: post #205
thwarted wrote: post #161

Earlier quoted context omitted.

But are you an expert in the IDE? Are they having a problem with git or are they having a problem with the IDE?

Every IDE I know shows you a log of the raw commands its running. I use the IDE first, then if something goes wrong (which very very rarely happens, git isn't exactly complicated) I check the log and see what it's trying to do.

On top of that, the IDE will let you run git directly in an authenticated session if you really desire. If a simple/dumb GUI wrapper around git is enough to scare off an experienced developer, then I have my doubts about their competence.

Re: New in Git: switch and restore

#386

Post by quickthrower2 »

thecupisblue wrote: post #58
papaf wrote: post #44

Earlier quoted context omitted.

How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning. Its probably a rhetorical question but I think its worth answering anyway. Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. If you are a new dev…

>Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. The depressing thing is I'm not talking just about off-the-shelf newbies, I'm also talking about experienced devs. >Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity. Yes, unfortunately, this is b…

I don’t know about most people but i have to relearn stuff if I don’t use it.

I use the basic git commands a lot but the wider set not very often.

So maybe I should learn Git from first principles every year? Like a cop would practice at the firing range?

But I’m doing that on my own time. But then what about the 1000 other things from Dockerfiles, to Relational database query plan optimisation, to the latest azure cloud offerings, to the newest React library for managing state, etc. etc.

Re: New in Git: switch and restore

#387

Post by Nursie »

jen20 wrote: post #373
Nursie wrote: post #349

Earlier quoted context omitted.

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

I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit. You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.

> You can always keep your working branches on a personal remote

This kinda defeats the point again, to my view. I’m not familiar enough with gists to know if they would solve this.

Re: New in Git: switch and restore

#388

Post by rwallace »

erikpukinskis wrote: post #305
z77dj3kl wrote: post #217

Earlier quoted context omitted.

A more apt comparison would be to using a saw vs using a saw with gloves on. With gloves it's safer and more comfortable, but you're not quite as in touch with the wood as you would be without one. Without gloves you feel badass because you don't care about safety, and you might be able to carve out some slightly more intricate things. Either way the outcome is roughly the same and it really doesn't matter what your…

I flagged this because this is extremely dangerous advice. DO NOT use gloves with a table saw, jointer, etc There are exceptions, but if you want a simple rule: DO NOT use gloves with power tools It is extremely dangerous. You can take an injury that would've been a nick on the finger and turn it into a lost hand.

Now I'm curious: why? Not that I don't believe you, but I'm wondering what is the reason? It's not intuitively clear why gloves would make it more dangerous, even knowing that it is.

Re: New in Git: switch and restore

#389

Post by Aeolun »

jbluepolarbear wrote: post #270
galangalalgol wrote: post #196

Earlier quoted context omitted.

I'll admit as a 20yr c++ developer, I don't know what rebase is or when to use it. I've only been using git for a few years, cvs before that. I commit and push often, then do a merge request via a web portal gui(bitbucket or gitlab), then merge it squashing commits again using the gui.

I prefer merge/fast forward because I want all history preserved. People can rebase their changes in their branch, but rebasing is never done on the main or development branches. Most of the worst merge conflict I’ve had to deal with were caused by someone rebasing changes they didn’t make. I reject all pull requests that change history.

I think this is generally the place where you rebase. Right before things go into the develop branch.

Re: New in Git: switch and restore

#390

Post by Stratoscope »

smt88 wrote: post #152
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

Good git GUIs (I use SmartGit and love it) do the following: - use the same terminology as git - show a log of every command - default to sane behavior - ask preferences instead of assuming (ex: rebase or merge?) - show warnings when doing something destructive or unusual I've found that I now spend zero time learning and thinking about git anymore, and it also protects our repos from git noobs at the same time.

Another SmartGit fan here. Adding to your list:

- Want a diff between two commits from two different branches? Click one commit and Ctrl+click the other. All the diffs show up immediately.

- Messed something up badly and you need to see the reflog? Click the Recyclable Commits checkbox, and everything in the reflog shows up just like any normal commit. And you can use the diff trick above on them.

- Wonder what's in your stashes that you forgot about? Click the Stashes checkbox and they all show up as normal commits. Because that's what a stash really is.

- Committed something to the wrong branch? Drag the branch markers to where you want them.

Post reply on HN