Earlier quoted context omitted.
GitHub's GUI is the worst. It has a "sync" button. As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to…
It just pushes the current branch afaik.
Oh shit, git: Getting myself out of bad situations
221–230 of 520 posts
Re: Oh shit, git: Getting myself out of bad situations
#222Adopted 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 think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.
Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users.
Sometimes dev obsession with tool purity does more damage than good.
Re: Oh shit, git: Getting myself out of bad situations
#223Earlier quoted context omitted.
> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.
Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.
Re: Oh shit, git: Getting myself out of bad situations
#224Git is easy once you understand it. What are people doing that is so difficult to understand?
Re: Oh shit, git: Getting myself out of bad situations
#225The very existence of such guides tells us a lot about how easy to use Git is :)
Re: Oh shit, git: Getting myself out of bad situations
#226I've said this before, but the business leadership, and tech leadership, need to think carefully about whether or not they need all of the power of Git. This sums up my concerns: ----------------------- Here are some minor failure modes I’ve seen with Git: 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) 2. data is erased for good because someone makes a mista…
> 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…
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.
Re: Oh shit, git: Getting myself out of bad situations
#227I think lists like these are part of the problem. You shouldn't rely on tricks to use git, you should understand how it works.
Re: Oh shit, git: Getting myself out of bad situations
#228Earlier quoted context omitted.
Almost everything on that list is wrong, but if I point something out (because I actually learned how it works), I'm just a predictable git fanatic? How is that different from burying your head in the sand?
because I actually learned how it works The argument is focused on those who can not learn how it works. See some of the other excerpts from the essay that are in this thread. Also, it's important to note that everything on that list is something that actually happened. Be careful about comparing your advanced skills to people with less skill than you.
If you're a software developer who uses branches and merges, you absolutely should learn how it works.
If you're an artist, git is not for you. It can neither store large binary files efficiently, nor merge them. There are other VCS that supposedly can, but I haven't tried them.
> Also, it's important to note that everything on that list is something that actually happened.
I can assure you, no data was permanently lost. What did happen is somebody couldn't find it, because they didn't know where to look. And I argue they should have, because git is not really that hard to learn (as a developer).