The zen of cvs: you learn to live with your mistakes. :) If you forget the space after the equals, you fix it in the next commit and move on, hoping to do a little better next time.
You can also consider using a linter and running it from the precommit hook.
I would appreciate this more if it had detailed explanations of the commands required to fix those situations. People should be encouraged to learn more git, not panic, Google, and copy-paste commands into their terminal.
Git has docs for commands once you know about the command. The explicit purpose of this page is to tell you what commands are needed to fix a problem. I appreciate the article keeping it brief.
That’s a pretty poor and limited set of examples - none of them involve you having pushed to origin, for example. I’ve found
to be the deus ex machina for my most terrible git mistakes… a soft reset before you’ve pushed hardly even qualifies as fixing a mistake anymore in my book.
Doesn’t that strike you as an indictment of git as a tool? If you frequently find yourself feeling the need to hack the commit graph, doesn’t that mean something is wrong with your development workflow?
On the contrary, git’s ability to rewrite history is one of its most useful features. Like all sharp tools, you can cut yourself with it if you’re not careful.
Nobody needs to know when, specifically, I pulled down the latest changes during branch development. That’s just noise. Rebase the branch, and you get a clean commit history.
Maybe I made three commits on the way to implementing a small feature, but in retrospect these commits don’t make much sense in isolation. A quick rebase -i and squash, and now you see everything you need in one diff.
Instead of your commits showing how the codebase got to where it’s at, you can edit and restructure your commits as a narrative to show why you’re making changes.
On the contrary, git’s ability to rewrite history is one of its most useful features.
Not at all my point. I’m not complaining that the feature exists, I’m pointing out that if that feature is needed often, because people are regularly screwing up commits, then something is radically wrong with the situation.
What’s wrong may be “the majority of developers who use git”, but it seems more likely that it’s git itself. And it’s not that feature set that’s the issue, it’s the workflow leading up to the use of that feature set.
(also, side note: /u/mbillie1 was bragging about frequently using git reflog, and your examples were all about git rebase, so it’s possible we’re simply talking about two different sets of use cases)
Note that mbillie’s comment was regarding the severity of the mistake, not the frequency.
side note: /u/mbillie1 was bragging about frequently using git reflog, and your examples were all about git rebase, so it’s possible we’re simply talking about two different sets of use cases
No, that was intentional. rebase and reflog are both tools for manipulating the commit graph. They are aspects of the same feature.
I think you have a point, but I also think it’s somewhat the fault of developers. There is a culture that every commit must be perfect, thus requiring one to edit messages, massage commits, and rewrite history. The tooling enables this, but doesn’t cause it.
The tooling plays its part in causing it. It includes things like bisect and git log -G, which make past history directly useful to the present. The noisier the history, the less useful such tools are.
git log -G
Sure, prettifying history is one thing. To say “a soft reset before you’ve pushed hardly even qualifies as fixing a mistake” implies that there are more significant problems happening than prettifying.
I wasn’t bragging about using it often at all, just saying that the worst mistakes you make can still be fixed with the reflog. When I see the headline “oh shit, git!” I tend to think of those very bad / difficult to undo mistakes, that’s all.
If you frequently find yourself feeling the need to hit the backspace key, does that mean something is wrong with your editing workflow?
If you’re hitting backspace to delete stuff added by your editor, and not by you? Yes.
What’s the analogy here? What is Git adding to the commit graph that the user didn’t put there?
Apparently the primary use case for prettifying history is merge commits, which are a thing added to your commit graph that are different than you making an edit.
I’ve found this flowchart to be really useful: http://justinhileman.info/article/git-pretty/full/
Regarding empty git diff output - there are three concepts you need to know: the index (where you’re cooking up the next commit), the currently checked out commit (HEAD) and the working directory (whatever is stored in your filesystem). There are three diffs you can make:
git diff HEAD
git diff --cached
If you add something to the index and run git diff then git won’t show any changes because the index and the working directory are the same.