Maybe you could let git influence and hopefully improve the way you work.
For instance, when refactoring something quite complex with good test coverage, you want each commit to be the smallest atomic commit that can pass all tests. But you also want to very quickly and "carelessly" add debug logs, assertions, changes in many files. For this kind of task I have found the following workflow to be very helpful and fast:
1. edit files relentlessly running a few tests cases
2. when you feel you "got" something run full test suite
3. if 2. pass, use `git add -p` to add the smallest changeset doing the thing.
4. Use `git stash --keep-index` to remove all other changes
5. Run full test suite
6. If 5. fails `git add -p` to continue editing your commit, or `git reset` if too far off
7. If 5. pass, `git commit` and `git reset --hard`.
Edit: When using `git add -p` you can even use 'e' command to manually edit your patch.
I'm sure that git with it's very powerfull backend has way for improving way someone works, but I'm not convinced by this example. IMO it shows again that usability of git is far from perfect. For example in bzr to accomplish this task you can:
1. (same)
2. (same)
3. put all changes that you are not interested in on shelve: `bzr shelve` (or qshelve if you want QT gui)
4. Run full test suite
5. If 4. fails keep editing
6. If 4. pass `bzr commit` (or `bzr ci`), and to revert shelving use `bzr unshelve`
You need to remember 6+ git command to accomplish this tasks, and only 3 with bzr. Moreover there is symmetry in bzr (fe: shelve - unshelve, commit - uncommit) that is no present in git.
> 3. put all changes that you are not interested in on shelve
Usually what I want is the opposite: cherry pick a few changes, increasingly adding them to the staging area (or index in gitspeak), because oftentimes I have a change that I am not sure is required for this patch.
I was very unconvinced by the staging area thing when starting using git and tried to avoid it, but in fact it is very powerful and not that complex. I do not know bzr and only used hg for a few months so maybe they have similar tools, but my main point is not git against the other, it is learn power uses of the tools to help improve workflow, against the claim that dcvs should be not our concern.
For instance, when refactoring something quite complex with good test coverage, you want each commit to be the smallest atomic commit that can pass all tests. But you also want to very quickly and "carelessly" add debug logs, assertions, changes in many files. For this kind of task I have found the following workflow to be very helpful and fast:
1. edit files relentlessly running a few tests cases
2. when you feel you "got" something run full test suite
3. if 2. pass, use `git add -p` to add the smallest changeset doing the thing.
4. Use `git stash --keep-index` to remove all other changes
5. Run full test suite
6. If 5. fails `git add -p` to continue editing your commit, or `git reset` if too far off
7. If 5. pass, `git commit` and `git reset --hard`.
Edit: When using `git add -p` you can even use 'e' command to manually edit your patch.