Re: [tlug] Chrome ate my profile

[Curt Sampson <cjs@example.com>]

On 2018-03-17 01:29 +0900 (Sat), Stephen J. Turnbull wrote:

> FWIW, that wasn't my use case.

Right. Actually, I had assumed you had a different use case, so was
just warning the other guy.

> I would frequently be working on some task, and notice a minor,
> non-reviewable defect (typo in a comment) or one of those defects
> that really annoys pedants but if you fix them people bitch about VC
> churn (trailing whitespace) or that it's hard to figure out what you
> actually did in the diff...

I fully agree with the folks who say that these sorts of changes
shouldn't be mixed into the same commit with functionality changes or
fixes.

However, I also agree with you that they ought to be fixed. There's an
easier way to do it though. (Or at least, I think it's easier, if I
understand correctly what you're doing.)

Every time you see something like this that needs to be fixed, just
fix it and commit it as a separate commit. You can do this via `git
add -p` to add and commit bits of your changes, or just `stash save`,
fix, commit and `stash pop`. Eventually you'll have a bunch of these
in your unpushed history.

Then you call on your bestest friend ever and forever, `git rebase
--interactive`. Move all of these little fixes up before your regular
work, squash as necessary, and now you have one or a few commits that
all come before your feature work. Fetch, rebase all this on to
`origin/master`, and push just those commits up on to your remote's
master branch to improve the world immediately.

How I combine them depends on what I'm trying to say to the other
developers. If it's a bunch of formatting or similar problems that I
know were just accidents and the devs really know what they should be
doing, I may push it all up as a large "fix lot o' formatting" blob,
expecting everybody to skip reading the diff. If there are particular
cases that developers need to learn from, I'll do separate commits
with readable diffs for those so that they can see "this is what it
was, and this is what it should be."

This technique I also use for refactorings. As I get deep into a
feature that's taking a long time (often hours! :-)) I'll find
refactorings I want to do to make implementing the feature easier.
These I'll also collect up, move them before all my feature changes,
and push up to origin's master earlier rather than later so that other
developers get the benefit of them sooner (and so that if they see the
refactorings are going the wrong way for something else, we can talk
about it now rather than later).

If you ever get things wrong, `git rebase --interactive` helps hide
this, too. Rather than pushing up to master a commit with an error
followed by another commit fixing it, move the fix back to just after
the commit with the error and squash or fixup. You may go through many
cycles of this on your dev branch, but by the time you're ready to
push your stuff onto master you'll have a byuuutiful series of
incredibly clear commits that make it look as if you knew exactly what
you were doing all along and never made a wrong turn.

(This last technique is not one I've ever needed myself, of course. :-))

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch