# cvsimport error: need a valid pathname 5 messages from 2005-08-27 to 2005-08-28. Participants: Kalle Valo, Martin Langhoff, Linus Torvalds, Junio C Hamano. Thread: https://gitlist.dev/t/1677 ## Kalle Valo, 2005-08-27 14:48 Subject: cvsimport error: need a valid pathname Message-ID: <874q9bcu6d.fsf@litku.valo.iki.fi> URL: https://gitlist.dev/e/874q9bcu6d.fsf%40litku.valo.iki.fi ``` I have already imported a full CVS repository using this command: git cvsimport -v -d :pserver:anonymous@hostap.epitest.fi:/cvs hostap It completed without errors and I could use git to access the hostap history, just like I wanted. But now, when I was trying to get updates from the CVS repository, I got an error running the command in the same directory: $ git cvsimport -v -d :pserver:anonymous@hostap.epitest.fi:/cvs hostap fileparse(): need a valid pathname at /usr/bin/git-cvsimport-script line 435 $ The documentation says that it should be possible to update incrementally from the CVS repository. Am I doing something wrong or is this a bug? I'm using git updated today from the master branch on Debian unstable. -- Kalle Valo ``` ## Martin Langhoff, 2005-08-27 15:37 Subject: Re: cvsimport error: need a valid pathname Message-ID: <46a038f905082708371719121c@mail.gmail.com> URL: https://gitlist.dev/e/46a038f905082708371719121c%40mail.gmail.com In-Reply-To: <874q9bcu6d.fsf@litku.valo.iki.fi> ``` On 8/28/05, Kalle Valo wrote: > The documentation says that it should be possible to update > incrementally from the CVS repository. Am I doing something wrong or > is this a bug? It _should_ work the way you are running it, so consider it a bug. Do you think you can do some tinkering/debugging to tell us some more? Otherwise. how large is the cvs repo? (Debugging this kind of stuff, when it only fails on a specific repo, is tricky and time-consuming. Any help we get is _really_ appreciated. I have imported many trees, and several of them I am tracking - importing new commits on a daily basis - without much trouble, except for invalid/force-moved tags.) cheers, martin ``` ## Kalle Valo, 2005-08-27 17:44 Subject: Re: cvsimport error: need a valid pathname Message-ID: <87zmr39svy.fsf@litku.valo.iki.fi> URL: https://gitlist.dev/e/87zmr39svy.fsf%40litku.valo.iki.fi In-Reply-To: <46a038f905082708371719121c@mail.gmail.com> ``` Martin Langhoff writes: > On 8/28/05, Kalle Valo wrote: >> The documentation says that it should be possible to update >> incrementally from the CVS repository. Am I doing something wrong or >> is this a bug? > > It _should_ work the way you are running it, so consider it a bug. Do > you think you can do some tinkering/debugging to tell us some more? I investigated it and realized that this was my mistake. I had copied the imported git repository from my laptop to my desktop using 'scp -r' and it changed .git/HEAD to a file, not a link as it should have been. I copied it again, this time with tar to preserve symbolic links, and cvsimport started to work again. So this was just a PEBCAK. Thanks for your help. > Otherwise. how large is the cvs repo? 'git log | grep commit | wc -l' says 2704 commits. I have to say that git has made my life a lot easier. It was really easy to import the CVS history to git and now I can read the history properly with gitk. With CVS I would have been banging my head to the wall all the time. Now all I want is svnimport and darcsimport :) -- Kalle Valo ``` ## Linus Torvalds, 2005-08-27 20:54 Subject: Make .git directory validation code test HEAD Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508271334320.3317%40g5.osdl.org In-Reply-To: <87zmr39svy.fsf@litku.valo.iki.fi> ``` Inspired by a report by Kalle Valo, this changes git-sh-setup-script and the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a symlink, since a number of core git features depend on that these days. We used to allow a regular file there, but git-fsck-cache has been complaining about that for a while, and anything that uses branches depends on the HEAD file being a symlink, so let's just encode that as a fundamental requirement. Before, a non-symlink HEAD file would appear to work, but have subtle bugs like not having the HEAD show up as a valid reference (because it wasn't under "refs"). Now, we will complain loudly, and the user can fix it up trivially instead of getting strange behaviour. This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY" being directories, since the other tests will implicitly test for that anyway (ie the tests for HEAD, refs and 00 would fail). Signed-off-by: Linus Torvalds --- On Sat, 27 Aug 2005, Kalle Valo wrote: > > I investigated it and realized that this was my mistake. I had copied > the imported git repository from my laptop to my desktop using 'scp > -r' and it changed .git/HEAD to a file, not a link as it should have > been. I copied it again, this time with tar to preserve symbolic > links, and cvsimport started to work again. So this was just a PEBCAK. diff --git a/git-sh-setup-script b/git-sh-setup-script --- a/git-sh-setup-script +++ b/git-sh-setup-script @@ -11,7 +11,6 @@ die() { exit 1 } -[ -d "$GIT_DIR" ] && +[ -h "$GIT_DIR/HEAD" ] && [ -d "$GIT_DIR/refs" ] && -[ -d "$GIT_OBJECT_DIRECTORY" ] && [ -d "$GIT_OBJECT_DIRECTORY/00" ] diff --git a/setup.c b/setup.c --- a/setup.c +++ b/setup.c @@ -72,6 +72,24 @@ const char **get_pathspec(const char *pr return (const char **) pathspec; } +/* + * Test it it looks like we're at the top + * level git directory. We want to see a + * + * - a HEAD symlink and a refs/ directory under ".git" + * - either a .git/objects/ directory _or_ the proper + * GIT_OBJECT_DIRECTORY environment variable + */ +static int is_toplevel_directory(void) +{ + struct stat st; + + return !lstat(".git/HEAD", &st) && + S_ISLNK(st.st_mode) && + !access(".git/refs/", X_OK) && + (gitenv(DB_ENVIRONMENT) || !access(".git/objects/", X_OK)); +} + const char *setup_git_directory(void) { static char cwd[PATH_MAX+1]; @@ -89,17 +107,8 @@ const char *setup_git_directory(void) offset = len = strlen(cwd); for (;;) { - /* - * We always want to see a .git/refs/ subdirectory - */ - if (!access(".git/refs/", X_OK)) { - /* - * Then we need either a GIT_OBJECT_DIRECTORY define - * or a .git/objects/ directory - */ - if (gitenv(DB_ENVIRONMENT) || !access(".git/objects/", X_OK)) - break; - } + if (is_toplevel_directory()) + break; chdir(".."); do { if (!offset) ``` ## Junio C Hamano, 2005-08-28 04:56 Subject: Re: Make .git directory validation code test HEAD Message-ID: <7v7je6slps.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7je6slps.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY" > being directories, since the other tests will implicitly test for that > anyway (ie the tests for HEAD, refs and 00 would fail). I've thought about it when you brought up the Andrew's naked git repository detection issue, but one thing I was undecided was that if we would want to forbid either of these "directories" being a symlink to another directory. I think it would be OK; admittedly "test -d" says OK for a symlink to a directory. I accept the patch, but will not apply and push it out right now; I am not in a shape to be operating heavy equipment ;-). Please wait until tomorrow morning. ```