Advice on strategy for "temporary" commits

Try if "git checkout -m" does what you wanted. Or simply
do a merge of "more often" branch into "less often" branch,
perhaps simply not recording it as a merge with
"git merge --squash" followed by "git commit".

By the way, you know that you can --amend a commit?

Jakub suggested primarily being on the temporary branch,
when updating the archival branch is desired to first commit
to the temporary branch, then switch to the archival branch
and do a "git merge --squash temp-branch-name" and commit.
This seems to half-work, in that when it doesn't flag a merge
conflict it does what I want. Unfortunately it often seems to detect
"conflicts" that aren't conflicts for my usage and which make
automatic cron usage impossible, eg,
-------------------------------- 8< -------------------------------
$ git merge --squash temp
 100% (4/4) done
Auto-merged s
CONFLICT (content): Merge conflict in s
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result.

$ more s
H1
t1
t2
<<<<<<< HEAD:s
=======
t4
t5

quoted

quoted

quoted

quoted

quoted

quoted

temp:s

--------------------------------- 8< ----------------------------
I _think_ if I could specify an opposite of the "ours" merge
strategy that always takes file contents from the other branches
head commit. An alternative might be to see if I can figure out directly
commiting the relevant file tree to both branches using low-level
git commands avoiding the higher level git processing (since
this isn't really a merge of different development but recording
the same "content state" on two different branches maybe
trying to make a "merge" work is the wrong idea.)

[In case anyone thinks I'm wrong to want to work primarily from cron
jobs, my rationale is that this stuff is personal to me -- ie,
won't be independently changed by anyone else -- and isn't
a focussed product. Years ago I tried using RCS on my home
directory and found I spent lots of time writing contentless
commit messages like "save
at 11.15 on 05/06/02" and that during crunch periods I'd
avoid making check-ins because it was too much extraneous
work; but these were _precisely_ the times I'd be most likely
to rush and do some stupid changes I'd want to back out, so it
didn't really work and so I stopped using RCS. With my "safety net
and historical archive" usage pattern -- which is different from
productised development -- I really want something safe to
run from cron.]

Anyway, thanks for all the help.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould