On Mon, Oct 17, 2016 at 11:28 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Stefan Beller <sbel...@google.com> writes:
>>> In any case, I find it more disturbing that we somehow ended up with
>>> a system where these three things are expected to behave differently:
>>>         A - path/to/dir
>>>         B - path/to/dir/
>>>         C - path/to/dir/.
>>> Is that something we can fix?
>> Well A, B are the same.
>> C is "obviously" different, when it comes to counting slashes for relative
>> path/url purposes, in the way that there are characters after the last slash
>> and just by coincidence '.' refers to the directory itself, C behaving like
>> 'path/to/dir/sub' seems right to me.
> It doesn't look right to me at all.  If you were contrasting
>         cd path/to/dir/sub && cd ..
>         cd path/to/dir/bus && cd ..
> then I would understand, but why should these two
>         cd path/to/dir/. && cd ..
>         cd path/to/dir/sub && cd ..
> behave the same?
>> So how do you imagine this fix going forward?
>> * Breaking existing users with /. at the end? by treating it the same as A,B
>> * Do some check based on time/version of Git and cover the old data?
>> * Forbid /. at the end from now on?
> Where at the end-user facing level does this trailing "/." surface
> and how does the difference appear to them?  I think that is the
> crucial question.
> Unless there is some convincing argument why "." is not special
> (i.e. counter-argument to the above "bus vs sub" and ". vs sub"
> example), I would think "existing users with /." does not matter.
> If they are "relying" on the behaviour, I would think it is not
> because they find that behaviour intuitive, but only because they
> learned to live with it.  IOW, treating all of A/B/C the same way
> would appear to them a strict bugfix, I would think.

I see, so we should adapt the windows style and chop off '/.'
to make A,B,C all the same, because internally we never produced

These came in via hand edited .gitmodules files.

> It is totally a different matter if OUR code that consumes the
> output from the submodule-helper --resolve-relative" internally is
> confused and relies on "../. relative to path/to/dir/. is the same
> as ../. relative to path/to/dir/sub" for whatever reason.  Without
> fixing that, I would not surprised if fixing things to treat A/B/C
> the same way would surface differences in the end-user observable
> behaviour in a negative way.

Reply via email to