git-import: fatal: not a git repository

[jgh9]

Hello. I get this error when running against a repository that I have cloned to disk:

fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git

[CNG]

Hello, could you provide more details? What command were you running, and what steps did you take first?

[jgh9]

I downloaded the raw file of your script. I changed permissions on it so it was executable. I pointed it to a folder within a repository I have cloned and received the error. I am running this on RedHat Linux 6.

I believe I see the issue now, though. It seem the script is expecting to run it from within the repository. I was running it outside of the checked out repository.

[CNG]

That's what I would guess, but I wanted to confirm what script you are trying to run, as there are many scripts in this repository!

[jgh9]

I just cloned an empty repository, and then went inside the directory and ran the script. It worked, but I still need to analyze commit. That being said, when I do a git add and follow it up with a git commit, I receive the following:

# On branch master
nothing to commit, working directory clean

[CNG]

I think you are misunderstanding me. We are corresponding right now on an issue you filed on github.com/CNG/dotfiles, which is a repository that contains the application that controls setting up my computers. Within its modules, there are many shell functions contained in script files. It seems you are talking about one in particular, but unless I missed it, you didn't specify which. So it's hard for me to look at any code to see what you might be running into.

That said, based on your description so far, I think you're talking about the file git-import? If that is the case, what you are seeing is expected. The script works by creating patches that are then applied to the repository from which the script is executed. After it applies the patches, the commits contained within the patches are part of the history of the target repository and do not need to be added and committed again.

Perhaps I should write more documentation for it. This was a step up from not having saved it anywhere at all!

[jgh9]

Yes, it is for git-import. With the information you put here, I created another repository and used your tool. After doing this, I just did a push and it worked great :) Thanks! Yes, documentation or even a message print out at the end about next steps would be helpful.

[CNG]

I was going to wait but decided to add CNG/dotfiles@ceacb19#diff-4b8f7cc6439d00f5e8f5de72ced87a6b for now. Could you let me know if that works and is sufficient for you? Thanks!

[jgh9]

Feel free to close this issue now. I will use the script on my next import and see how it goes, and test this issue. If something else happens, I will open a new issue. Looks about right, though.

[jgh9]

I received this error when running the import:

[helfman@p-host ~/workspace/test123 11:26:42]
> ../git-import.sh ../abc/test123
Must be inside Git repository work tree where provisioning is to be imported.
../git-import.sh: line 20: return: can only `return' from a function or sourced script
[helfman@p-host ~/workspace/provisioning 11:26:44]

I am trying to import from abc/test123 to a new repository call test123. I am executing this from within the new repository and pointing to the older location of abc/test123

If I remove the check, then I am able to run the script.

[pitoneux]

Same here. So I removed the test too and it works but with some error messages. But it looks like it did the import fine. SourceTree shows the right thing happens. I did the push and I'm golden.
Note: I'm trying to import a file in my new repo that doesn't have the full directory structure to the imported file yet. So my new repo, where I ran the git-import is basically empty. Was cloned from an empty new repo. By removing the test (like jhelfman did), I managed to get the file to get imported albeit with some error on the console.

Here is what I got:

git-import ../mylocalrepo/directory/myfile.h
[...]
.git/rebase-apply/patch:54: trailing whitespace.
warning: squelched 65 whitespace errors
warning: 70 lines add whitespace errors.

not sure what are those.

thanks for that script tho! wish git would have been written by humans sometimes...

[pitoneux]

ah.. when I try to import a directory (instead of a single file) I got:

error: directory1/directory2/file.h: already exists in working directory
error: directory1/directory2/file.m: already exists in working directory
Patch failed at 0245 Renamed files
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

there is no file called .git/rebase-apply/patch and everything seems to be back to before I tried this.

hmmm...

[CNG]

Hey there, I will try to look at this tonight. Regarding your last comment, that is because this line in the script automatically causes the abort:

git am "$temp"/*.patch || git am --abort || :

You could remove the || git am --abort || : portion and try again to be able to inspect the files as the Git messages are suggesting. And remove the last line, rm -rf "$temp" to keep the patches! But then check that it gets deleted eventually...

[CNG]

Sorry for the delay. I pushed bab34538756f1f02501fb4a05de352236283d00c to address these two:

• Accidentally redirected both stdout and stderr in the test of git rev-parse, hence the function exiting prematurely.
• "can only return from a function or sourced script" because the script was written to be autoloaded by Zsh, and hence it was not wrapped in a literal function. Since autoloading still works even with wrapped functions, I converted it so git-import can be called as a script as well. This worked by executing the function with script parameters with git-import "$@" immediately following the function definition.

I don't think I will address the "already exists in working directory" issue now since I wasn't intending this to overwrite existing files and I would need to think about the implications of doing so on the commit history or how it should be handled.