> I'm guessing the cvs2git version changed in the upgrade and the new version
> generates different commit hashes from the old one. You can verify this by
> comparing how a known commit shows up on the GitHub UI vs. a git log of a
> recent cvs2git conversion: if the "commit XXXXXXX" strings differ, that's
> our culprit.
>
> If you don't care about preserving the hashes of the old commits on GitHub,
> then what you probably want is `git push --mirror origin`. It does exactly
> what it sounds like, mirroring the current state of the entire repo to the
> remote. (Doing this means that people won't be able to git pull without
> --rebase on checkouts of your repository made prior to the cvs2git upgrade,
> and if there are any antediluvian forks of it on GitHub the UI may get
> confused trying to figure out their relation.)
>
> If you DO care about preserving the commits with the old hashes on GitHub
> then I don't know how to do better than Anton's suggestion, though I think
> you'll still encounter problems with tags... you'd have to take the --tags
> off your push command and come up with some system for pushing new tags
> individually.
Lari,
Modifying the script with "--mirror" as suggested by you and a private
message fixed this for me. For completeness:
cd /a/tmp/path
cvs2git --blobfile=git-blob.dat \
--dumpfile=git-dump.dat \
--username=mymail /path/to/REPO
mkdir $1.git
cd $1.git
git init
cd .git
git fast-import --export-marks=../../git-marks.dat < ../../git-blob.dat
git fast-import --import-marks=../../git-marks.dat < ../../git-dump.dat
git remote add origin https://github.com/account/REPO.git
cd ..
git checkout
git push origin --mirror # This fixed everything.
This worked beautifully. Thanks again for the help!
Best,
Kristaps
No comments:
Post a Comment