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

481–490 of 520 posts

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

#481

Post by compiler-guy »

yes_or_gnome wrote: post #461
compiler-guy wrote: post #452

Earlier quoted context omitted.

“Nobody submits them, or nobody cares to vote them up.” That should tell you something: these articles don’t resonate with the crowd. That should tell you something.

I take your original comment as an indictment that git is somehow broken by design. Which sure, you're entitled to an opinion, but to bring up SVN in the same breath is absurd. That's why I replied. I can't really address p4 because I haven't used it for any real world use cases. Only to prepare for an interview. With that limited use, I can't come with any reason to think it's superior.

You take my original comment incorrectly. I said nothing about how git is designed and how it may be broken. I made no claims about how Perforce may or may not be superior. I made no claim as to how SVN may or may not be superior.

I made exactly one claim:

These git cheatsheets on how to get out of a bad state get a lot of traction on Hacker News. That is a pretty good indicator of something. Let's think about what that is. The fact that you consider it a serious indictment of git should also tell you something.

I'll make another claim now though:

When someone criticizes git, some users sure get defensive about it. That should also tell you something.

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

#482

Post by nullterminator »

swalsh wrote: post #123
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 the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…

I use both.

Staging, especially partially staging hunks and lines when doing multiple things at once, is way easier in a GUI when you can scroll around for context and easily undo.

For everything else I prefer the command line, because it's faster and I know exactly what is going to happen. I can do what I need to do, no fighting. If I'm just committing everything, I use the CLI. If it's more complicated I use the GUI to stage and commit, and a CLI to rebase/merge/push.

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

#483

Post by geezerjay »

dasil003 wrote: post #247
dilap wrote: post #187

Earlier quoted context omitted.

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model. The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations…

The way you confuse git porcelain with git CLI makes it quite clear that you know nothing about either. I'm yet to find a GUI for any VCS that comes close to doing a job as good as any CLI.

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

#484

Post by mseebach »

sigjuice wrote: post #334
mseebach wrote: post #177

Earlier quoted context omitted.

It's not ideal, at all -- and if someone else has pushed in the meantime, they risk losing the commit. But if you're in a situation where doing this would be a significant problem, you should probably not be pushing directly to master in the first place, instead relying on a PR workflow.

Why not simply push a second commit that reverts the broken commit? This will avoid rewriting history and messing up the rest of your team.

Because that will pollute the history and diminish its value as a record of what happened in the code base. For instance, blame will no longer tell you when a line was changed, but rather point to the revert commit. Bisect breaks if it divides through the reverted commits.

Of course, rewriting history is only feasible immediately after the mistaken commits, before anyone builds on top of them. If they've lingered, reverting is the right way.

And again, if this is a repeating problem, fix it upstream (no pushing to master, only PRs).

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

#485

Post by geezerjay »

chiefalchemist wrote: post #464
dasil003 wrote: post #418

Earlier quoted context omitted.

You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made…

Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.

> Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.

It looks like you mindlessly associate a CLI with a poor -- or suboptimal -- user experience. In fact even your choice of weasel words conveys the idea that you want to mindlessly push an irrational belief in spite of not being able to provide arguments to support it. The truth of the matter is that git -- or any other VCS -- operated through commands that change the current state of the repo. The command line interface excels when the user wants to run commands. Any GUI developed for command line tool will end up doing nothing more than replicate what the CLI already does, and will do so poorly.

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

#486

Post by nothrabannosir »

rhencke wrote: post #456
nothrabannosir wrote: post #442

Earlier quoted context omitted.

> Git is fundamentally better than most of the alternatives No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously. I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, la…

1. Git LFS is not part of Git. It's an unofficial extension, despite the name. I've got my own qualms about Git, but that's like complaining about GitHub's forking model as a reason Git is bad. 2. Microsoft uses Git in single large-scale mono repo form, for - believe it or not - Windows. It clocks in at about 3.5 million files, and a full clone weighs in at 300GB: https://blogs.msdn.microsoft.com/bharry/2017/05/24/th…

Git LFS is not part of Git.

That’s my point: without LFS it’s even worse to work with large files. If LFS is the best option you have, forget it. That’s an entire area of projects (anything with assets) you can’t use Git for.

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

#487

Post by welly »

Ajedi32 wrote: post #79
welly wrote: post #71

Earlier quoted context omitted.

If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.

Git Kraken isn't FOSS. The site says "Free for non-commercial use", and AFAIK the source isn't available anywhere. I think maybe the term you're looking for is "freeware"?

Ah, you're quite right. I was under the impression it was FOSS - I used it a while ago, preferred Tower and so went back to that.

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

#488

Post by welly »

Froyoh wrote: post #283
welly wrote: post #71

Earlier quoted context omitted.

If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.

How is atlassian's Sourcetree?

We have a bunch of projects that are stored in a mercurial repo so I've been using Sourcetree for that as I've found MacHG pretty unusable. I think it's pretty good, not as good in my opinion (the UI, mainly) as Tower for Mac which I use for Git, but makes Mercurial easy to use for this (somewhat) hardened Git user.

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

#489

Post by welly »

machiaweliczny wrote: post #320
welly wrote: post #71

Earlier quoted context omitted.

If you're on a mac, I can't recommend Tower enough. It's a paid app but well worth the money. Otherwise Git Kraken is a foss offering that is also excellent.

Gitup is free and probably better.

Thanks for the tip, I'll have to check it out.

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

#490

Post by falsedan »

falcolas wrote: post #439
falsedan wrote: post #398

Earlier quoted context omitted.

That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream. When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pu…

Anytime you normalize a workflow around using unsafe commands, you risk desensitization to those very warning messages you're relying on to save you. If you have one rebase with a force push a week, people will quickly stop asking "who did the force push", since it has become normal. They'll instead just let the force push come through to their local repo, just to find out that the force push rolled the repo back a y…

I think this is fine, but then I'm comfortable with what a force-push is (a remote reset) and I know that the commits still exist even when the ref is moved, and how to inspect the history of a bare repo to move the ref back.

I don't understand the business requirement for a non-lossy repo. In my experience, we need to be able to link a release to a specific commit, and we need to show that the changes were reviewed & tested before they were deployed. We use tags for this.

I also think the entire purpose of source control is to be able to answer question like "who changed this? when was it changed? why?".

> Now productivity is halted dead

Because of a bad push to a single repo? I really like the distributed nature of git, which lets me stay productive even when other repos and branches elsewhere are having issues. I would avoid treating git as 'SVN but newer'.

Post reply on HN