Re: [PATCH 2/2] git submodule: Fix adding of submodules at paths with ./

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Feb 25, 2009, 12:35 UTC
Message-ID: <49A53B15.4060608@drmicha.warpmail.net>
In-Reply-To: <49A529AB.8010700@viscovery.net>

Johannes Sixt venit, vidit, dixit 25.02.2009 12:21:

Show 9 quoted lines

> Michael J Gruber schrieb:
>> +	# strip superfluous ./ from path
>> +	path=$(echo "$path" | sed -e 's|^\(\./\)*||' -e's|/\./|/|g')
> 
> At a minimum:
> 
> 	path=$(echo "$path" | sed -e 's|^/\(\./\)*|/|g' -e's|^\./||')
> 
> Otherwise you would turn "foo./bar" into "foobar", right?

Wrong.

My regexp: echo "foo./bar" | sed -e 's|^\(\./\)*||' -e's|/\./|/|g' foo./bar

echo "foo/./bar" | sed -e 's|^\(\./\)*||' -e's|/\./|/|g' foo/bar

Your regexp: echo "foo./bar" | sed -e 's|^/\(\./\)*|/|g' -e's|^\./||' foo./bar

echo "foo/./bar" | sed -e 's|^/\(\./\)*|/|g' -e's|^\./||' foo/./bar

Testing your claim isn't that hard to do before hand...

> But why only care about ./ but not ../ or /// or trailing / as well?

You really haven't even looked at the included context of the patch (which you stripped), have you? I mean, I'm open for suggestions and criticism, but please don't shoot blindly.

./ have been reported and are a common use case.

Trailing / are dealt with by the code (see context).

Now, the /// are in fact a valid concern[1], although probably not that common an isue. If we really want to cater for that (and more) we need to implement normalize_path_copy() (from path.c). There it says:

* Performs the following normalizations on src, storing the result in dst:
 * - Ensures that components are separated by '/' (Windows only)
 * - Squashes sequences of '/'.
 * - Removes "." components.
 * - Removes ".." components, and the components the precede them.
 * Returns failure (non-zero) if a ".." component appears as first path
 * component anytime during the normalization. Otherwise, returns
success (0).

OK, two more regexps for sed. Thanks, I don't need suggestions for the regexps ;)

I can add /// and .. testing and handling in a v2, but I'll definitely leave the Windoze paths to someone who can actually test on Win.

Michael

[1] git sm init uses git ls-files, which in turn,..., which calls normalize_path_copy. git sm add can't use git ls-files because it has to deal with an as yet unknown path.