Slightly orthogonal but a less destructive way of 'Fuck this noise' is to use worktrees. They were a game-changer for me. I often have several tasks on the go and it's really useful to have different branches in different directories and not have to stash changes if I need to quickly switch to a different task.
Oh Shit, Git
71–80 of 237 posts
Re: Oh Shit, Git
#72Earlier 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.
It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions. I bet git produced by a no name Linus, in isolation not required by any major project, would have hardly been taken any major uptake.
> It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions.
I think parent's point is that that demographic is positively tiny, and there were plenty of other serviceable offerings around at the time.
The claim stands - git won despite its UX flaws, which does suggest the alternatives, while serviceable, weren't sufficiently fit for purpose.
Re: Oh Shit, Git
#73Just curious, are people here still using master or did you migrate to main?
I saw no reasons to change.
Re: Oh Shit, Git
#74Earlier 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'd argue the opposite - that the model was so good and so much better than anything else that it was adopted despite the UI/UX flaws. Things can be good, have a flaw and still be considered good. That doesn't mean that we pretend the flaw doesn't exist.
Mercurial is built on what is almost the same model and has what I think is a better UI/UX. Some people say that git is technically superior but you really need to be an advanced user for it to matter, or work on a really large project.
At work, we switched from SVN to Mercurial, and from Mercurial to Git. Most people were happy to switch away from SVN, but few enjoyed the change from Mercurial to Git. Personally, it took me much longer to get used to Git than with Mercurial, even though Mercurial was my first DVCS. I now have a slight preference for git, but I am happy with either (just don't bring back SVN!).
Why Git came to dominate and not Mercurial? I am not sure, but I don't think technical reasons explain everything. Its association with Linux probably helped a lot.
Re: Oh Shit, Git
#75Just curious, are people here still using master or did you migrate to main?
"using master" can imply being a leech. You should replace it with "working with master".
"people here" could be interpreted as "you people". Please remove it from your comment.
Re: Oh Shit, Git
#76Git 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.
You shouldn’t present your own opinions as facts. I find Git intuitive, and it works as I expect it to do. I suspect a lot of people agree since Git became the champion of the DVCS crusades.
Re: Oh Shit, Git
#77Earlier 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.
It dominated the world because GitHub was better than BitBucket and had more generous free levels. If only that wasn’t the case we’d all be using a sensible source control system now instead of one where people repeatedly say things like “if you just learn the underlying model…”
It's not even an anecdote but, uh, I prefered hg to git until the day I tried to use it on a system with the wrong Python installed...
(I like Python! But it's a scripting language, not a systems language. Also the "deployment story" is bananas.)
Re: Oh Shit, Git
#78Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.
Is it, though? I'm not so sure.
Git has enjoyed overwhelming success, which would seem to empirically indicate that it's done something right in terms of design
Perhaps the obviously wrong UX/UI isn't wrong? Perhaps UX/UI people aren't good at designing interfaces for experts?
Re: Oh Shit, Git
#79If you stick to master-only development things like commiting to the wrong branch can't happen: https://medium.com/@mattia.battiston/why-i-love-trunk-based-...
If you cut off your limbs, you can’t get gangrene either.
Re: Oh Shit, Git
#80I think the steps under https://ohshitgit.com/#accidental-commit-master are wrong: it reverts the commit on the new branch -NOT on the master. This is because git branch auto checks out the new branch. You need to do git branch NEWBRANCH git checkout master git revert —hard HEAD^ If you want to continue working on the new branch you do git checkout NEWBRANCH
The steps I see on the website are:
git branch some-new-branch-name
git reset HEAD~ --hard
git checkout some-new-branch-name
0. prior state is that we're on master and have committed something that should have been on a branch
1. create a new branch that is identical to master (i.e., contains the commit) -- note this does NOT checkout the new branch (`git checkout -b some-new-branch-name` would do that)
2. reset current branch (master) to point at the commit before (i.e., strips the commit from master)
3. checkout the new branch to continue work there
At the end, master doesn't contain the commit anymore, and the new branch does. It's all correct.