Solve jsonn/pkgsrc.git breakage

gistfile1.md

The problem

jsonn/pkgsrc.git, our upstream repository, has been corrupted due to the cvs conversion from cvs.netbsd.org going awry with 'cvs admin -m' usage.

The issue is manifest when trying to merge:

$ git remote -v
origin  git@github.com:joyent/pkgsrc.git (fetch)
origin  git@github.com:joyent/pkgsrc.git (push)
upstream        git://github.com/jsonn/pkgsrc.git (fetch)
upstream        git://github.com/jsonn/pkgsrc.git (push)

$ git branch
  joyent_gccruntime
  joyent_multiarch
* trunk

$ git status
# On branch trunk
nothing to commit (working directory clean)

$ git log --no-merges -1
commit 050c1f6d7d6d02b94df55b554a8066bd814f0500
Author: obache <obache>
Date:   Fri Sep 21 12:45:01 2012 +0000

    apply missing the first hunk of the patch for PLIST in PR 46573.

$ git merge upstream/trunk
git merge upstream/trunk
Auto-merging x11/xvidcap-gtk2/Makefile
CONFLICT (content): Merge conflict in x11/xvidcap-gtk2/Makefile
[.. many conflicts skipped ..]
Auto-merging audio/abcde/Makefile
CONFLICT (content): Merge conflict in audio/abcde/Makefile
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 4517 and retry the command.
Automatic merge failed; fix conflicts and then commit the result.

Something is clearly corrupt, as for example the log for audio/abcde/Makefile shows that it hasn't been touched since before we last merged.

$ git log --no-merges -1 audio/abcde/Makefile
commit 97a8634a3574c79773f7454d60877d1be17daf4b
Author: asau <asau>
Date:   Tue Sep 11 23:59:21 2012 +0000

    "user-destdir" is default these days

Possible workarounds

See if upstream can be fixed it.

joerg is currently unavailable, but ideally upstream would be mangled back into a working state where the merge is clean. This may not be possible, depending upon

Merge implicitly from upstream then re-merge our changes.

Possibly, but I'd be worried about losing changes or history, and merging the breakages from upstream might cause issues for downstream repositories of ours?

Merge from upstream but retaining our version, then re-merge upstream changes

The opposite approach to the above, should be simpler and hopefully less prone to errors? The drawback of this approach is that the commit ids no longer match for commits done during the merge period, but as this time frame is reasonably short (3 days) it appears to be the least-worst option.

Implementation:

# Get back to normal
$ git reset --hard origin/trunk

# Get current revision we have tracked from upstream
$ git log --no-merges -1
commit 050c1f6d7d6d02b94df55b554a8066bd814f0500
Author: obache <obache>
Date:   Fri Sep 21 12:45:01 2012 +0000

    apply missing the first hunk of the patch for PLIST in PR 46573.

# Get upstream diff since then
$ git diff 050c1f6d7d6d02b94df55b554a8066bd814f0500 upstream/trunk >~/upstream.diff

# Merge in upstream/trunk but ignore their changes
$ git merge --no-commit -s ours upstream/trunk

# Now apply the upstream diff.  www/nginx/options.mk doesn't apply so force and merge manually.
$ git apply --reject ~/upstream.diff
$ vi www/nginx/options.mk
$ rm www/nginx/options.mk.rej

# Commit the lot
$ git add inputmethod/scim/patches/patch-extras_immodules_common_scim-bridge-messenger.c \
          inputmethod/scim/patches/patch-extras_immodules_common_scim-bridge-string.c \
          multimedia/fuppes/patches/ \
          security/cyrus-sasl/patches/patch-saslauthd_Makefile.in \
          www/nginx/Makefile.cflags
$ git commit -a