Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

Post reply on HN
Print view View original

231–240 of 520 posts

Re: Oh shit, git: Getting myself out of bad situations

#231

Post by quicklyfrozen »

ashelmire wrote: post #203
lwansbrough wrote: post #42

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

Git is, imo, way too simple to require a gui. How long is it taking you and your coworkers to make commits? git commit -am "message" (or add the files you want with git add, then commit); git push; git pr -m "message". The longest part of that is coming up with a good commit message. A gui isn't going to stop people from making mistakes because the mistakes aren't from complexity of the command line, they are from co…

For me, using a GUI makes it much less likely I'll commit the wrong changes as I can quickly review each staged file across the entire tree before committing, and also see if there are unstaged changes (including new files which was often the bane of an SVN workflow) which need to be included.

I typically use git gui to commit changes, the cli for other operations, and occasionally source tree to visualize branches and compare with remote repos.

Re: Oh shit, git: Getting myself out of bad situations

#232

Post by rootlocus »

burstmode wrote: post #226
rootlocus wrote: post #58

Earlier quoted context omitted.

> 2. data is erased for good because someone makes a mistake while using rebase No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them. And rebasing generates new commits, leaving the old ones exactly how they were. If somebody lost a commit after a rebase, and nobod…

>If somebody lost a commit after a rebase, and nobody nearby could help them recover it, they should consider spending a few hours learning about git. GIT is the only source control system where you can completly loose commited data by actions (or commands) available the non-admin user. It's funny to see that this is considered a "feature" and not a design failure.

> completly loose commited data

Except the whole point is that you can't completely lose commited data, even if you tried really hard. And the solution to the problem was `git reflog` which shows the history of the HEAD.

Re: Oh shit, git: Getting myself out of bad situations

#233

Post by emodendroket »

michaelmior wrote: post #221
emodendroket wrote: post #205

Earlier quoted context omitted.

It just pushes the current branch afaik.

So it never pulls updates on the remote? That seems like pretty unexpected behaviour.

It pulls and then pushes, I guess I should say, but I was considering "pulls and..." part of the push operation.

Re: Oh shit, git: Getting myself out of bad situations

#234

Post by klmr »

dasil003 wrote: post #206
reificator wrote: post #164

Earlier quoted context omitted.

> committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

Say you have 3 sequential lines, but you only want to stage the middle one. You can’t split it into smaller hunks by hitting ‘s’ during ‘git add -p’. I’m sure there’s a way I’m just not familiar with but I just use Sourcetree for this on the rare occasion it occurs.

You can split hunks manually by editing (hit “e” instead of “s” during staging). I end up doing this fairly regularly.

Re: Oh shit, git: Getting myself out of bad situations

#235

Post by rootlocus »

lkrubner wrote: post #185
ryanbrunner wrote: post #88

Earlier quoted context omitted.

I'm not necessarily the biggest git fan in the world, but here's some refutations to some of these concerns: > 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) This is more of a workflow question than a VCS question, and would be true of any VCS that allows branching (i.e. anything remotely close to a modern VCS) > 2. data is erased for good because someone ma…

* there's no reason you have to use all these git features * If you are not using all of the Git features, then why use Git? Why not use something simple, like Subversion? As I wrote in the linked essay: ------------------- When I list these complaints for developers, most of them respond “You are complaining about Git’s power. The stuff you list isn’t really a flaw, rather those are all examples of how amazing Git i…

Because git is magnitudes of times faster, and it's the most widespread VCS in the world at the moment.

Re: Oh shit, git: Getting myself out of bad situations

#236

Post by lhabjane »

bootcampjs wrote: post #105
lillesvin wrote: post #85

Earlier quoted context omitted.

My biggest issue with a GUI is that most that I've seen introduce new terms for various stuff, e.g. "sync" in VS Code, or "revert commit" (in Source Tree maybe?) — there's no Git command called "sync" or "revert", so I'm not immediately sure what they do. In a CLI I know exactly what's happening. That's just my opinion though. If people feel comfortable working in a GUI all the more power to them.

I work with a lot of people who have no idea how git actually works and it is infuriating. They all use the git desktop program, and almost every time I get called over to help, it’s because they didn’t sync or refresh or whatever the hell it does. If you don’t have a good mental model for git, you’re gonna have a bad time.

Second this. I was one of those people that needed help when I was learning git. Went full CLI after that and never looked back.

Re: Oh shit, git: Getting myself out of bad situations

#237

Post by cytzol »

Pxtl wrote: post #141
lwansbrough wrote: post #42

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

I use both - to me the big advantage of getting used to GIT CLI is that you learn the tools to handle uncommon operations and automate tasks, which the GUI doesn't give you. When you need to start piping stuff through grep, for example.

GUI user here. Genuine question: when would you need to pipe stuff through grep? I get it would be a rare situation, but I can't think of one.

Re: Oh shit, git: Getting myself out of bad situations

#238

Post by [deleted] »

lwansbrough wrote: post #42

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

[deleted]

Re: Oh shit, git: Getting myself out of bad situations

#239

Post by tarsius »

dilap wrote: post #192
aldanor wrote: post #186

Earlier quoted context omitted.

There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does. The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal). If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets…

Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

I think Magit could be classified as a TUI [1].

But that still doesn't help explain its benefits to someone who hasn't tried it. For the crowdfunding campaign that I ran earlier this year I wrote a few articles. For those unfamiliar with Magit I would recommend [2] and the more visual [3].

[1] https://en.wikipedia.org/wiki/Text-based_user_interface [2] https://emacsair.me/2017/09/01/the-magical-git-interface/#st... [3] https://emacsair.me/2017/09/01/magit-walk-through/#start

Re: Oh shit, git: Getting myself out of bad situations

#240

Post by legohead »

So I just ran across this one: git diff --staged

I added a file and wanted to diff it, and this command helped! However, I made some changes in the file, and when I tried this command a second time, the changes don't show up :\ Only the original file that was added shows up in the diff. Now what? It's not the end of the world of course, as I can just look at the file in my editor, but I usually use diffs as a personal code-review before I commit.

Post reply on HN