fast-export icon indicating copy to clipboard operation
fast-export copied to clipboard

hg-fast-export executed successfully but the files are not copied to the new git repo

Open indranilse opened this issue 2 years ago • 9 comments

I have successfully run the hg-fast-import command as below

command run from the git repo: "path where sh file is~\hg-fast-export.sh" -r "repo for the hg"

This is the result fast-import statistics:

Alloc'd objects: 5000 Total objects: 0 ( 0 duplicates ) blobs : 0 ( 0 duplicates 0 deltas of 0 attempts) trees : 0 ( 0 duplicates 0 deltas of 0 attempts) commits: 0 ( 0 duplicates 0 deltas of 0 attempts) tags : 0 ( 0 duplicates 0 deltas of 0 attempts) Total branches: 0 ( 0 loads ) marks: 1024 ( 0 unique ) atoms: 0 Memory total: 2399 KiB pools: 2048 KiB objects: 351 KiB

pack_report: getpagesize() = 65536 pack_report: core.packedGitWindowSize = 1073741824 pack_report: core.packedGitLimit = 35184372088832 pack_report: pack_used_ctr = 0 pack_report: pack_mmap_calls = 0 pack_report: pack_open_windows = 0 / 0 pack_report: pack_mapped = 0 / 0

but after this the new GIT repo is still empty. Next when I execute the git checkout HEAD it is throwing error error: pathspec 'HEAD' did not match any file(s) known to git

Can you please help to resolve.

indranilse avatar Sep 16 '21 09:09 indranilse

Fast-export does not touch your working directory and that is by design. In Git, HEAD is the head of the currently checked out branch, if no branch is checked out, doing git checkout HEAD is expected to produce the error you report. As fast-export can't know which of (potentially) multiple converted branches you want checked out after a conversion, it leaves that up to the user. Check the git documentation for how to list and checkout branches.

frej avatar Sep 16 '21 10:09 frej

@frej sorry to confuse you. What I mean is the GIT repo which we created is still empty after the conversion. it has only the .git folder. If I am still missing any steps can you please guide me with the next steps please if possible.

indranilse avatar Sep 16 '21 17:09 indranilse

Looking at the output again: Total branches: 0 and commits: 0 seems to indicate that nothing was found in the Mercurial repo. The information you have provided is not enough to even guess what could be wrong, there should be output [edit: from fast-export] before the information you quoted [edit: (from git fast-import)]. In general:

Please have a look at this blog post about writing effective bug reports. For fast-export you should at least:

  • Report the version of the fast-export you are running, tag and/or hash.

  • Check if your problem is solved by using the latest released hg-fast-export.

  • Check that your installed versions of Python and Mercurial meet the minimum requirements as specified in the README.

  • Explain what you are trying to do, how you are doing it and in what environment. This includes relevant parts of the used mapping files.

  • If your source repository is publicly available, give the URL.

  • If hg-fast-export gives an error message and a backtrace, include that in the issue. Also include the relevant parts of the crash report created by git fast-import.

frej avatar Sep 16 '21 20:09 frej

@frej Thank you for being patient. Here is the details which I am trying to achieve. Prerequisites: Mercurial 5.4.2 is installed with Python 2.7 , all are added in the system path variable.
The repo is a java repo with java and xml files

  1. The mercurial source code is hosted on a internal server over intranet which I am cloning it into c:\tmp\hg-repo
  2. I am creating a empty GIT repo in c:\tmp\git-repo
    • git init c:\tmp\git-repo
  3. cloned the fast-export
    • git clone https://github.com/frej/fast-export.git
  4. Go to cd c:\tmp\git-repo
  5. c:\tmp\fast-export\hg-fast-export.sh -r c:\tmp\hg-repo - once this command is run from git bash the following is generated
  6. $ c:/tmp/fast-export/hg-fast-export.sh -r c:/tmp/hg-repo c:/tmp/fast-export/hg-fast-export.sh: line 198: C:\Python27;C:\Python27\DLLs;C:\Python27\Lib; C:\Python27\Lib\lib-tk; C:\Python27\libs; C:\Python27\Scripts;C:\Python27\tcl;C:\Python27\Tools: No such file or directory fast-import statistics:

Alloc'd objects: 5000 Total objects: 0 ( 0 duplicates ) blobs : 0 ( 0 duplicates 0 deltas of 0 attempts) trees : 0 ( 0 duplicates 0 deltas of 0 attempts) commits: 0 ( 0 duplicates 0 deltas of 0 attempts) tags : 0 ( 0 duplicates 0 deltas of 0 attempts) Total branches: 0 ( 0 loads ) marks: 1024 ( 0 unique ) atoms: 0 Memory total: 2399 KiB pools: 2048 KiB objects: 351 KiB

pack_report: getpagesize() = 65536 pack_report: core.packedGitWindowSize = 1073741824 pack_report: core.packedGitLimit = 35184372088832 pack_report: pack_used_ctr = 0 pack_report: pack_mmap_calls = 0 pack_report: pack_open_windows = 0 / 0 pack_report: pack_mapped = 0 / 0

  1. The git-repo remains empty with only .git folder created at time of git init

Please let me know if you need any information to resolve this issue as we have multiple repos in hg internally hosted which we need to move to GIT and Bitbucket.

indranilse avatar Sep 17 '21 20:09 indranilse

This is clearly something that is broken or missing in your Windows environment. Your shell fails to execute the Python part of fast-export. It could be that the PYTHON environment variable is set to a list of paths when it should point to the python interpreter to use. Issue #160 could be relevant, but I'm just guessing.

Windows is not a platform I have access to, nor interest in, and support for it depends on contributions from users, so you are on your own debugging this. Checking historic issues marked with the wintendo label could give you some pointers.

frej avatar Sep 18 '21 13:09 frej

@indranilse: Please update this issue if you figure out what is wrong, that way the next Windows user stumbling on this problem is helped too.

frej avatar Sep 23 '21 08:09 frej

I ran into the same issue. It seems the problem is with the branch names. The latest versions of git uses "main" for the default branch, where it used to be "master".

To fix the issue simply add the option "-M main" to the command.

hg-fast-export.sh -r <path-to-local-hg-repo> -M main

@frej Maybe this tool hg-fast-import could auto-detect the current branch name to fix this issue also.

ejohnson-dotnet avatar Oct 14 '21 18:10 ejohnson-dotnet

@ejohnson-dotnet are you sure that you have the same problem as @indranilse? Does your conversion crash with the same error message about failing to execute something looking like a $PATH? If you have the same problem, git fsck will not produce a Checking objects: 100% (<n>/<n>), done.-line after the failed conversion if you did the conversion in a fresh repo.

The latest versions of git uses "main" for the default branch, where it used to be "master".

As of today (211015), the latest released Git is 2.33.1 and as far as I can tell, it defaults to master unless you have set init.defaultBranch to something else.

I strongly suspect that the problem you have worked around with -M main is unrelated to the problem in this issue and you could have avoided repeating the conversion by doing git checkout master followed by a git branch -m main if this was a one-off conversion.

frej avatar Oct 15 '21 16:10 frej

UPDATE

It is normal that the target git repo folder will stay empty! Since the .git folder in it holds all of the new metadata, and files do not get put in the target git repo folder at all.** See "NEW" below.

Old (likely, this run-twice bug story is wrong):

This seems to be a bug, perhaps from needed flags or environment variables during runtime or anything else in the .hg or .git folders that needs to be there before the start?

At least, here is a proof by example that I had to run it twice: first run had 0 migration, and the same command run again right after no changes got the migration done.

2022-03-28_18-18

NEW (likely, fast-export just works):

EDIT: I cannot guarantee the above sayings anymore since I found out that I had another command prompt open in which I had tested a lot and in which I might have removed the new git folder. Then, the .git folder gets removed as well, which is needed to make a fresh restart, else, the migration will always stay 0. Therefore, delete the target folder for your git repo, init that git repo folder again to get the default .git folder, and then run the fast-export migration again. As I know from >10 runs with the same outcome after posting that screenshot above, this is needed to get out of the trouble of 0 migrations, and it is likely not about running it twice.

It is normal that the target git repo folder will stay empty. But check the .git in it, it will be changed after the migration and will have all of the branch and file metadata. Then git checkout and git push to the online git repo, and you will see that all of the files were fetched from the old hg folder.

The files do not pop up in the target git repo folder after migration, and that for a clear reason: the files do not need to be copied to the git folder at all since they are the same as in hg. Why would you want to copy a whole bunch of files to another folder only to upload them when a pointer to the address of the file in hg is enough to fetch them? The migration script needs to make git metadata for all commits, MRs, branches and so on from the given hg metadata, that is all.

There are error messages from git after the push that some refs could not be reached, but I checked this: there is no way to get rid of the errors, and there is also no need to do so, since the repo has all of the files and metadata anyway.

_After about 20 tries of various settings, with the same 0 migration as in this issue at first as well, but then learning more and more about the installer, I guess this issue can be closed. It is likely just one of these two misunderstandings:

  • .git folder was not renewed after a failed migration
  • there is a misunderstanding that there should be files in the target folder (no: the target folder will never show any files since copying the files to the target folder is not needed for a working push to git).

lorenzznerol avatar Mar 28 '22 17:03 lorenzznerol