Git mirror for trunk is out of sync

[dliessi (Davide Liessi)]

The trunk Git mirror (​​git://git.macports.org/macports/trunk.git) is at r148499 while the SVN repository is at r148743.

(High priority because it used to work and now it is broken.)

[mf2k (Frank Schima)]

The Priority field is for use by Macports team members only who will determine the priority.

[dliessi (Davide Liessi)]

Sorry, I won't change it next time. I thought it was ok because of this: ​https://trac.macports.org/ticket/49488#comment:1

[ryandesign (Ryan Carsten Schmidt)]

I agree this can be high priority, but I don't know how to fix it. The post-commit hook is running, the git sync script is running, and the only unusual thing in the log is that git-svn crashed after importing this revision:

        M       dports/net/libgweather/Portfile
Couldn't find revmap for https://svn.macports.org/repository/macports/users/devans/GNOME-3/stable/dports/net/libgweather
r148499 = 35bcce39e997904756821b0afa1d8b0e6879bb27 (refs/remotes/trunk)
error: git-svn died of signal 11

[danielluke (Daniel J. Luke)]

some googling says that this is caused by git-svn being confused by svn:mergeinfo (so probably r148494). It looks like the git repo doesn't have the 'users' directory so it's failing because it can't find the parent for this merge (it's in part of the svn repo that isn't in the git repo).

I don't know what the fix for that is, though (maybe a git or git-svn expert can chime in?)

[ryandesign (Ryan Carsten Schmidt)]

But this would hardly be the first time Dave has merged from his GNOME branch to trunk, and it hasn't caused this problem before.

[danielluke (Daniel J. Luke)]

That's true, perhaps there's some # of missed lookups that triggers the crash (and before the crash it's OK to just ignore the warning because we don't care that the merge parent isn't recorded for this case)?

It does look like git-svn uses a cache for merge lookups ($ENV{GIT_DIR}/svn/.caches/lookup_svn_merge) - it might be worth moving aside that file if it's there and seeing if that allows it to regen the cache and continue further.

[ryandesign (Ryan Carsten Schmidt)]

Thanks, I also found pages on Google suggesting moving aside the caches, since the name suggests they are merely caches which it should be possible for git to recreate from other data. I moved aside the .caches directory and reran the sync script which appears to have completed successfully and created a new .caches directory. I see that the lookup_svn_merge.db file in the new .caches directory is around 13K in size, while in the old .caches directory it was 0B.