Re: [tlug] Chrome ate my profile

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2018-04-06 13:53 +0900 (Fri), Stephen J. Turnbull wrote:

 > > They *are* commits.  They're just on a branch that is used only by
 > > this function, which function is invoked by XEmacs automatically every
 > > time I save.
 > 
 > I seem to hear you saying you generate a new commit every time you
 > save.

Yes, on a branch that will never ever be pushed anywhere.

 > I have no idea how that could work. It's not at all like my
 > workflow.

How could it be?  There's a big difference between your job and mine:
you generate a lot of new code, whereas when I was using that
workflow, I was reviewing, debugging, and occasionally fixing,
typically many unrelated fixes.  The "feature branch" mentioned was
often debugging scaffolding and attempted/partial fixes.

 > I usually save every few to few dozen seconds[1], but commit only
 > every few mintues to few tens of minutes.

I normally wasn't typing anywhere near enough to justify that pace of
saving, but the pace of commits under an "explicit commit" workflow
would have been more frequent in order to separate irrelevant fixes
from the mainline.  Here, I suppose it's typical if you're generating
new code.  In that case, none of the intermediate autocommits are
interesting, so I just squash the autocommit branch with

    git checkout mainline
    git merge --squash autocommit
    git commit -m "Informative commit message"
    git checkout autocommit
    git reset --hard mainline

(of course there's a macro for that).

 > Having a hundred commits with no messages to sort through would be a
 > nightmare for me. But I'm probably missing something here.

In my experience, with my tasking and workflow, it was rarely more
than a dozen, and I'd step through the diffs in gitk to triage the
commits with uninformative "autocommit" log messages.  I did try an
autocommit hook function that prompted for a commit message, but even
with a default to "typo fix" that turned out to be more distraction
than the information content of the log was worth for me.  (It's
interesting that *fixing* typos or even clarifying docstrings didn't
distract me as much from the main task as constructing the occasional
commit message or deciding to accept the default message did!)

I think pretty clearly this whole thing is very much YMMV.  I just
want to present it to show what's possible and how in a specific role
it worked for me.

I should also reiterate that I don't use this workflow any more.  It
wasn't feasible with Mercurial, let alone Bazaar, for reasons of
speed, so I didn't use it with Python or Mailman.  It was sufficiently
useful for me to use git that for XEmacs, hosted on Bitbucket in
Mercurial repos, I would maintain a git mirror of the Mercurial
repos.  But that's pretty painful, and with XEmacs development slowed
to a crawl, it's not been worth it for 5 years.  In my personal git
repos, there are no other reviewers, so no real point in separating
out "trivial" commits.

Now that both Mailman and Python are hosted in git, if I ever get
really active in either, I might revive the workflow.

 > [1]: These days it's often to trigger a test run,

That's an interesting concept, test-on-save.  How much testing does
that trigger?

 > though there's also a hold-over reflex from an ancient unreliable
 > VAX.

Reliability in the sense of what a save can buy you has never been an
issue for me, since Emacsen autosave every few hundred keystrokes or
handful of minutes.  The critical issue here is sorting changes into
"self-approve", "needs review", and "not ready for prime time" streams.