Oh Shit, Git?

I'm not a git user, but stuff like this really drives home the idea that "git commit" is meaningless, the only thing that matters is when your commits are pushed or merged.

It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.

If I'm saving changes that were done because of a arduous debugging journey and other people are likely to have to refer back to it, yes. In fact, forget little; the smaller the change is, the bigger the text. Some of my changes have 2-3 paragraphs for a 2-3 line change because of the impact.

Same here. If it took me a week to figure out why to tweak a couple lines of code, I'm going to be explaining it.

(Although also/mainly in the comments if it's something I worry someone might accidentally change back later.)

Well, it is all local until you push so you can do whatever you want.

With that said, it obviously is not meaningless at a technical level because without the commit there is nothing to push or merge. On top of that, at a non-technical level it can be extremely helpful to record some plain-english prose to describe why you are changing something. If you find yourself doing that too often you need to narrow your definition of what constitutes a "change" and/or be more discerning about what you work on simultaneously.

Out of curiosity, if you do not use git, what do you use for version control and change-management?

Commit is what causes git to make a copy of the file(s) internally. It's vitally important. But there is no point typing in silly messages like "more fixes" etc. What I do is make an initial commit with something like "(WIP) too feature", then keep doing amend commits until I'm happy, at which point I remove the "(WIP)" from the message.

I actually use git for my todolist/diary and I have an alias for when I want to save which does git commit -m "whatever." Basically I do that so I can view the updated version in the mobile app.

It seems painfully obvious to me that local and remote commits serve different purposes. Local commits are a way to create checkpoints when everything compiles and works and you can move on to the next step. That way you can stash your changes and go back to a working state when you screw things up. Then, before you push those changes, you reset them and split them into proper commits. That way the history is all nice and clean on the remote and it's not just a bunch of "wip"s.

Or you can just squash-merge your PRs and reap both benefits.

Even better, `git merge --no-ff` your PRs and use `git log --first-parent` for the simplified "as-if-it-was-squashed" history.

>It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.

Do you write a little message about your day every time you go to sleep?

I actually don't, and maybe you don't, but plenty of people do.

I think of the Git revision log as much like that sort of diary, offering the same sorts of advantages. It's more organized than having a separate TODO list document; and it encourages you to describe what you've already done in a clear readable way, too. When you're trying to figure out how far to roll back, it may be useful to understand what you were thinking at the time of the commit. And if something turned out to be the wrong approach, it helps you do the post-mortem.

And, of course: if your unmerged, unpushed work is organized into separate changes that have separate (and labelled goals), and part of that work turns out to be good and part bad, it becomes vastly easier to preserve the good parts.

I think people would generally have an easier time with git if they didn't try to fix their commit histories and instead just let their past mistakes be known. If you make a bad commit in git the best solution is to follow it up with a good one that fixes the problem. Squash commits on PRs help too.

I have no pride. I push my dumb commits that chronical my weird journey full of sub-junior mistakes to get to the final state.