2018-03-09 14:23 GMT+01:00 Ian Campbell <ijc@xxxxxxxxxxxxxx>: > On Fri, 2018-03-09 at 14:04 +0100, Michele Locati wrote: >> Just a couple of questions: >> >> 1. it seems to me it's not possible to process all the branches in one >> go. Am I right? > > I'm not sure, I've never done such a thing, in fact I didn't know you > could. > > Really all this feature does is record the `.git/rewrite-map` (or > whatever the correct name is) at the end of the rewrite and reinstate > it again the next time, so it shouldn't really interact with many of > the other options. > > My method for storeing "last version processed" in a branch does > conflict I suppose (since that branch would be rewritten) but that's an > artefact of the surrounding scaffolding -- you could equally well keep > the record in some file on the local system or in a non-branch-ish ref > (I guess). > >> 2. Why do you have this line in filter.sh? >> `rm -f .git/refs/original/refs/heads/${UPSTREAM_REWRITTEN}` > > TBH I'm not really sure. I originally wrote this patch many years ago, > it's just recently that I got around to upstreaming, so my memory is > more fuzzy than might be expected. > > I think perhaps I was trying to avoid this error: > > A previous backup already exists in $orig_namespace > Force overwriting the backup with -f" > > which comes if there is an existing backup (a safety feature in the > non-incremental case). > > Note quite sure why I didn't use `-f` as the message says, but I guess > because it forces other things too which I didn't want to do? > > Perhaps what I should have done is make that check conditional on the > use of --state-branch. > > I wonder if you could use the `original/refs/...` as the "last version > processed"? Would be a lot less manual messing around than what I do! > > Ian. I managed to get a general script that seems to work: see https://github.com/mlocati/incremental-git-filter-branch Thanks again, Ian. -- Michele