Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind.<p>When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.
Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements.<p>And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc.<p>And of course there is the interesting rabbit hole of semanitc / language aware diff. Line diffs suck in many ways.<p>It's one of the hundreds of of problems that I'd love to work on one day, but probably won't get a chance to. Sigh... :)
One thing that I had been looking for for a long time, but never could find, was a description of the several syntaxes you can use to refer to specific commits. Lots of git tutorials use these magic incantations, but none point you to this crucial bit of explanation.<p>Recently I discovered that it is found under "git help revisions".
> I committed and immediately realized I need to make one small change!<p>I think it might be nice to add a disclaimer saying that this is not advisable if you've already pushed the code. Suck it up and make a new commit–don't rewrite public Git history.
Same idea, but much more comprehensive: <a href="https://github.com/k88hudson/git-flight-rules" rel="nofollow">https://github.com/k88hudson/git-flight-rules</a>
I prefer this, because it has a flow-chart
<a href="http://sethrobertson.github.io/GitFixUm/fixup.html" rel="nofollow">http://sethrobertson.github.io/GitFixUm/fixup.html</a>
Git is nice tool, very versatile in able hands. Thanks to its promotion (plugins and github included), the pragmatic practice of source versioning gained wider adoption and lost that beg-your-IT-dept-to-set-it-up flair.<p>In the mean time, 'thanks' to Git, the source change history became a maintenance line-item. The expectations of a clean history were raised almost to the level of expectations for bug-free code.<p>I can see a utility of clean feature history, but asking developers to craft the history is shifting their focus away from the actual code. As long as the source state has been saved, the source control has done its main job.<p>So for the most of the listed 'shits', the developer should just be able to revert, cherry-pick, and re-commit, and keep going. Nothing esoteric and hard to remember, also fairly common commands across different VCS tools. Shit happens and will happen again, no biggie, no need to blame and shame, source annotation will show the right change/comment anyway.
Git performs like what it is : a piece of code created by debugging a blank sheet of paper. I can detect almost no philosophy and no simplifying assumptions. The thought that you need 60+ commands (the current size of my git cheat sheet, including all the bizarre argument incantations which seem customized for all 100+ possible mistakes in git) to get through the day is an abomination. I prefer perforce which requires less than 20 commands. The only reason people use git is because, Linus.<p>Like no good program, ever, to use git you have to understand all the compromises and all the internals of its data structures. What a joke.
> I use reflog A LOT<p>If you need to reset with reflog a lot you're probably using git wrong.<p>Sure it can be useful but I don't see why it should be in a workflow.
> git diff --staged<p>The way it worked well was that the "--staged" flag would be implied if you had already staged some files to be committed.<p>But on this day I noticed that nothing bad happened from that behavior. So I time traveled back and whispered to the git devs that the interface should be made more pedantic to keep users from relying too much on git to do the right thing for them.<p>Now it's great because users suffer and I have plausible deniability from this now being on par with the rest of git's interface.
Oh shit, this commit message buried by new commits must be fixed before it is propagated to other repositories.<p>Oh shit someone has fixed an old commit message that was already pushed to other repositories.<p>Oh shit, this commit ough to be a merge commit. The tree is good, but not the parents.
The last example [0] really should reference the obligatory XKCD [1]<p>[0] <a href="https://ohshitgit.com/#fuck-this-noise" rel="nofollow">https://ohshitgit.com/#fuck-this-noise</a><p>[1] <a href="https://xkcd.com/1597/" rel="nofollow">https://xkcd.com/1597/</a>
Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn.<p>This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day going through something like this: <a href="https://wyag.thb.lt/" rel="nofollow">https://wyag.thb.lt/</a><p>It will make you better at git and better at programming. Git is a powerful tool and you need to <i>learn</i> how to use it. Imagine if people read articles like this one instead of learning how to drive.
I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch.
Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok.<p>Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical mastery of the tool is very easy to achieve.<p>I honestly think this is a pedagogical lack. We tell everyone it's this complex thing and that they should be scared of rebase and the reflog and they believe it. Maybe if we didn't, it'd be easier.