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
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@xxxxxxxxx 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html