Re: [PATCH 6/6] Teach core object handling functions about gitlinks

On Tue, 10 Apr 2007, Frank Lichtenheld wrote:

On Mon, Apr 09, 2007 at 09:20:29PM -0700, Linus Torvalds wrote:

quoted

@@ -2332,6 +2333,8 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
 				     path);
 		free(target);
 		break;
+	case S_IFDIR:
+		return resolve_gitlink_ref(path, "HEAD", sha1);
 	default:
 		return error("%s: unsupported file type", path);
 	}

Not that I have time right now to look up the exact context (only read
the patch), but I would've expected a "case S_IFDIRLNK:" here?

So we have this strange (and worrying) dualism inside git: we use the same 
macros *both* for "stat data" *and* for "git-internal file modes".

So sometimes a mode is the result of a [l]stat() call like above, and then 
a gitlink is just a directory and we use S_IFDIR. And if it comes from the 
index, then it uses the internal git representation, and is S_IFDIRLNK.

I'm not very happy about it, but I'm actually most unhappy about it since 
I could imagine that the constants themselves are different on different 
OS's (eg VMS - a Unix-related OS will use the same constants for 
historical reasons).

In this particular place (index-path), we obviously not only have a stat() 
result, but more importantly, we never come here for a "normal" directory, 
since a normal directory would have been expanded into its component paths 
by the "read_directory()" logic.

So that interaction with directory expansion is somewhat non-obvious: 
normal directories are expanded recursively into the files they contain, 
while git directories end up being visible to internals as real 
directories, and are turned into gitlinks by code like the above.

		Linus