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

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 03.03.2009 16:36:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> Michael J Gruber schrieb:
>>> +	# normalize path:
>>> +	# multiple //; leading ./; /./; /../; trailing /
>>> +	path=$(printf '%s/\n' "$path" |
>>> +		sed -e '
>>> +			s|//*|/|g
>>> +			s|^\(\./\)*||
>>> +			s|/\./|/|g
>>> +			:start
>>> +			s|\([^/]*\)/\.\./||g
>> Sorry to say: not yet. This turns "a/b/c/d/../../../d" into "a/b/c/d"
>> instead of "a/d". Drop the 'g'.
>>
>> Once this is fixed, I have to ask what should happen with path names like
>> "../a/b", "../../a/b"? Should there be a warning or error?
>>
>> Other than that, this expression works on AIX 4.3.3! Note in particular
>> that '\n' in the printf format string is essential!
>>
>>> +			tstart
>>> +			s|/*$||
>>> +		')
> 
> At some point you should wonder if all of this complication is worth it,
> or it makes sense to reject when you see // or /\.\./ in the input.

I surely do wonder now! This started off treating merely leading ./ as
reported problematic by AT. Then the "do it really right" competition
started, and I think J6t and I came out as clear winners. There were no
other contenders.

Seriously, "git submodule init" does that normalization (by using
ls-files), so I think it does make sense to have it for add as well. git
submodule itself may have semi-porc/semi-plumb character, but if someone
wants to add submodules programmatically there is no simple way around
using "git submodule add", and paths may very well be constructed
relatively.

Michael