cvsimport error: need a valid pathname

cvsimport error: need a valid pathname

[Kalle Valo]

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

Re: cvsimport error: need a valid pathname

[Martin Langhoff]

On 8/28/05, Kalle Valo <Kalle.Valo@iki.fi> 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

Re: cvsimport error: need a valid pathname

[Kalle Valo]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> On 8/28/05, Kalle Valo <Kalle.Valo@iki.fi> 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

Make .git directory validation code test HEAD

[Linus Torvalds]

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 <torvalds@osdl.org>
---

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)

Re: Make .git directory validation code test HEAD

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> 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.