Git(Hub) and CVS

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Git(Hub) and CVS

Kristaps Dzonsons
I know many here are using CVS, and many are also using git, so I wonder
if anybody can help me.  On BSD.lv, I push my CVS repositories (kcgi,
sblg, etc.) to GitHub from time to time using a cvs2git script.  It goes
as follows, shortened and pseudonymised:

 REPO=$1  # e.g., kcgi
 cd /tmp/cvs2git
 cvs2git --blobfile=git-blob.dat \
   --dumpfile=git-dump.dat \
   --username=kristaps@me \
   /path/to/cvsroot/$REPO
 mkdir $REPO.git
 cd $REPO.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 --tags -u origin master

Our repositories are all pretty basic (just tags, no branches), and it's
only me pushing to GitHub, so this works although it's not incremental
and can take a minute or so.  Or I should say it "worked", because since
updating OpenBSD from an embarrassingly old version, it doesn't any
more.  The error given is on the push:

 Compressing objects: 100% (633/633), done.
 Writing objects: 100% (2257/2257), 492.44 KiB | 16.98 MiB/s, done.
 Total 2257 (delta 1624), reused 2257 (delta 1624)
 remote: Resolving deltas: 100% (1624/1624), done.
 To https://github.com/account/REPO.git
  * [new tag]         VERSION_0_4_3 -> VERSION_0_4_3
  ! [rejected]        master -> master (fetch first)
  ! [rejected]        VERSION_0 -> VERSION_0 (already exists)
  ... lots of"rejected" lines...
 error: failed to push some refs to 'https://github.com/account/REPO.git'
 hint: Updates were rejected because the tag already exists in the remote.

Any ideas?  Or does anybody have a process already in place for syncing
CVS to git/GitHub?  I've tried stopping before the "push" and doing all
manner of fetches and such, but nothing works.  I rarely use git, so I'm
really just reaching out in the dark.  The GitHub presence is just to
pick up on a issues and pull requests from folks who are more
comfortable with that interface than e-mail, for which it has worked well.

Thank you,

Kristaps

Reply | Threaded
Open this post in threaded view
|

Re: Git(Hub) and CVS

Anton Lindqvist-2
On Fri, Jan 19, 2018 at 01:43:08PM +0700, Kristaps Dzonsons wrote:

> I know many here are using CVS, and many are also using git, so I wonder
> if anybody can help me.  On BSD.lv, I push my CVS repositories (kcgi,
> sblg, etc.) to GitHub from time to time using a cvs2git script.  It goes
> as follows, shortened and pseudonymised:
>
>  REPO=$1  # e.g., kcgi
>  cd /tmp/cvs2git
>  cvs2git --blobfile=git-blob.dat \
>    --dumpfile=git-dump.dat \
>    --username=kristaps@me \
>    /path/to/cvsroot/$REPO
>  mkdir $REPO.git
>  cd $REPO.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

Prior pushing, have you tried;

  $ git fetch
  $ git branch -u origin/master
  $ git rebase

>  git push --tags -u origin master
>
> Our repositories are all pretty basic (just tags, no branches), and it's
> only me pushing to GitHub, so this works although it's not incremental
> and can take a minute or so.  Or I should say it "worked", because since
> updating OpenBSD from an embarrassingly old version, it doesn't any
> more.  The error given is on the push:
>
>  Compressing objects: 100% (633/633), done.
>  Writing objects: 100% (2257/2257), 492.44 KiB | 16.98 MiB/s, done.
>  Total 2257 (delta 1624), reused 2257 (delta 1624)
>  remote: Resolving deltas: 100% (1624/1624), done.
>  To https://github.com/account/REPO.git
>   * [new tag]         VERSION_0_4_3 -> VERSION_0_4_3
>   ! [rejected]        master -> master (fetch first)
>   ! [rejected]        VERSION_0 -> VERSION_0 (already exists)
>   ... lots of"rejected" lines...
>  error: failed to push some refs to 'https://github.com/account/REPO.git'
>  hint: Updates were rejected because the tag already exists in the remote.
>
> Any ideas?  Or does anybody have a process already in place for syncing
> CVS to git/GitHub?  I've tried stopping before the "push" and doing all
> manner of fetches and such, but nothing works.  I rarely use git, so I'm
> really just reaching out in the dark.  The GitHub presence is just to
> pick up on a issues and pull requests from folks who are more
> comfortable with that interface than e-mail, for which it has worked well.
>
> Thank you,
>
> Kristaps
>

Reply | Threaded
Open this post in threaded view
|

Re: Git(Hub) and CVS

Kristaps Dzonsons
>> I know many here are using CVS, and many are also using git, so I wonder
>> if anybody can help me.  On BSD.lv, I push my CVS repositories (kcgi,
>> sblg, etc.) to GitHub from time to time using a cvs2git script.  It goes
>> as follows, shortened and pseudonymised:
>>
>>  REPO=$1  # e.g., kcgi
>>  cd /tmp/cvs2git
>>  cvs2git --blobfile=git-blob.dat \
>>    --dumpfile=git-dump.dat \
>>    --username=kristaps@me \
>>    /path/to/cvsroot/$REPO
>>  mkdir $REPO.git
>>  cd $REPO.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
>
> Prior pushing, have you tried;
>
>   $ git fetch
>   $ git branch -u origin/master
>   $ git rebase

Anton,

Thanks for taking a look!  Results of running this after the checkout:

 % git fetch


 ...
 From https://github.com/account/REPO
  * [new branch]      master     -> origin/master
 % git branch -u origin/master
 Branch master set up to track remote branch master from origin.
 % git rebase
 First, rewinding head to replay your work on top of it...
 Applying:
 Using index info to reconstruct a base tree...
  [...stuff about white-space...]
 warning: 3 lines add whitespace errors.
 Falling back to patching base and 3-way merge...
 Auto-merging source.c
 CONFLICT (add/add): Merge conflict in source.c
  [...a few more messages like that...]
 error: Failed to merge in the changes.
 Patch failed at 0001
 The copy of the patch that failed is found in: .git/rebase-apply/patch

 When you have resolved this problem, run "git rebase --continue".
 If you prefer to skip this patch, run "git rebase --skip" instead.
 To check out the original branch and stop rebasing, run "git rebase
--abort".

Any further ideas?  I wish I could be more helpful, but my git fu is weak.

Best,

Kristaps

Reply | Threaded
Open this post in threaded view
|

Re: Git(Hub) and CVS

Lari Rasku
In reply to this post by Kristaps Dzonsons
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.

Reply | Threaded
Open this post in threaded view
|

Re: Git(Hub) and CVS

Kristaps Dzonsons
> 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