Idk, am I the only one thinks Git is really not that hard? At all?
Oh Shit, Git
111–120 of 237 posts
Re: Oh Shit, Git
#112Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.
We had Mercurial but it died, not with a bang, but with a whisper ...
Mercurial is still actively developed, and isn't really "dead", although it did lose a lot of popularity and "mindshare".
Projects like Firefox and nginx use it, although others like Vim and Python switched to GitHub. I don't know if Facebook is still using Mercurial internally, but for their public stuff they use GitHub.
I think that if GitHub had supported Mercurial like BitBucket or Google Code it would still be a lot more popular, but ah well...
Re: Oh Shit, Git
#113Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.
Git's UI/UX is one of the worst engineering sins to be committed in the last two decades, and this website shows why. Literally nothing about git is intuitive and the "underlying model" is entirely ad-hoc. Instead of celebrating how Linus built git in only a few days he should be castigated for knowingly setting up ill-conceived software to go viral.
Git is definitely not ill-conceived and jealously castigating Linus for creating it and freely giving it away is no more than a petty insult.
Re: Oh Shit, Git
#114It would be nice to see something like this for Magit.
Also, the fact that this is so complicated and that this document is as long as it is is strong evidence that git is just poorly designed from a UI standpoint.
Re: Oh Shit, Git
#115Idk, am I the only one thinks Git is really not that hard? At all?
No. (edited: by that I mean you are not the only one)
Re: Oh Shit, Git
#116Earlier quoted context omitted.
Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.
I've worked with CVS, Subversion, Bazaar, Visual SourceSave, Team Foundation Version Control, Mercurial and Git. The worst systems are the Microsoft ones, but the one with the most complex interface is definitely Git. I would argue it won because of github. I'm using Git because of that, but still prefer Mercurial in every way.
I agree with this. Mercurial is cool, but if you need to convert your Mercurial project to Git to push to GitHub, then it's a fucking pain.
Re: Oh Shit, Git
#117Earlier quoted context omitted.
I spend my life in git. I never ever had to just erase everything and clone again. I do not see a situation where it would be needed honestly.
It's needed when you're somebody who doesn't want to spend their life in git and just want to undo a mistake.
It's not going to help when one fucks up a complicated merge/rebase and can lose a ton of work if something goes wrong. Understanding what you're doing goes a long way.
I've seen this a couple of times at $DAYJOB when someone doesn't understand how rebase works, smashes keys until it looks like they've achieved their goal, and then I have to ssh into their box and try to unravel the damage they've done, hoping that reflog has not been GC'd yet and there's something to revert to.
Re: Oh Shit, Git
#118I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…
As a counter point. Every time I've seen people get themselves into trouble with git has been when they are using a GUI tool. I have yet to see a gui tool that they can use to get themselves back out of it. There's a lot of value in knowing your way around the command line side of git even if you regularly use gui tools to interact with the repository.
Re: Oh Shit, Git
#119Earlier quoted context omitted.
That just resets to your last local commit. To sync back up to the remote, you need at least do a git reset origin/HEAD --hard (and capitalization matters, I don't know why). But that doesn't work if you rewrote history in some way (I'm not sure why that's even possible). In that case your local git can get pretty messed up, some gui tools (IntelliJ) start to bug out and fail to diff properly, and it's easier to just…
Not sure what origin/HEAD is supposed to point to. HEAD is a ref that points to the tip of the current branch. It's not going to be available for remotes (it just doesn't make sense). To reset the current branch, you need to do two things: $ git fetch to fetch commits from the default remote and point remote branches accordingly, and $ git reset --hard origin/master to reset HEAD to the remote branch. Substitute mast…
I don't know what the difference is, honestly :( I believe you, but I see both online and nobody seems to know the difference and it seems to work. Shrug? Most of my git life is copy pasting somebody else's commands because the model of it is really too complex for me. I've given up on caring... it's easier and faster to rewrite some code than deal with git's commands.
Same thing for node modules, lol. Delete the folder and try again. If that still doesn't work, delete the lock file and try again.
It's a terrible practice, I know, but it's the only thing that actually seems to work in my experience.
EDIT: Apparently origin/master points to a specific branch. origin/HEAD points to the top of the "default" remote branch, which is often, but not always, master. Or something like that. I don't know for sure.
Re: Oh Shit, Git
#120I have used this resource, until common stuff has burned into brain "choose your own git adventure": https://sethrobertson.github.io/GitFixUm/fixup.html
Came here to post this - better than the link under discussion above. The interactive steps through a problem helps a ton for diagnosing the right steps to fix something!