Re: What's cooking in git.git (Oct 2016, #03; Tue, 11)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio,

On Fri, 14 Oct 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> >> >> * sb/submodule-ignore-trailing-slash (2016-10-10) 2 commits
> >> >>   (merged to 'next' on 2016-10-11 at e37425ed17)
> >> >>  + submodule: ignore trailing slash in relative url
> >> >>  + submodule: ignore trailing slash on superproject URL
> >> >>
> >> >>  A minor regression fix for "git submodule".
> >> >>
> >> >>  Will merge to 'master'.
> >> >
> >> > Going by the bug report, this *may* be more than
> >> > minor and worth merging down to maint as well, eventually.
> >> 
> >> The topic was forked at a reasonably old commit so that it can be
> >> merged as far down to maint-2.9 if we wanted to.  Which means the
> >> regression was fairly old and fix is not all that urgent as well.
> >
> > And if you merge it to `master` and `maint`,...
> 
> I'll mark it as "wait for follow-up fix" in whats-cooking.txt (on
> 'todo' branch) to remind myself not to merge it yet.

May I request your guidance as to your preference how to proceed? Here is
the problem: Stefan's fix uncovered a bug in the way Git for Windows' Bash
hands off "Unix" paths to real Windows programs, such as `git
submodule-helper`: trailing `/.` gets truncated to `/`.

That is, when passing `/c/test/.` to the helper, what arrives is
actually `C:/test/`. So the helper, being expected to cut off trailing
slashes, cuts it off because it does not see the dot.

Note: when passing URLs (`https://repos.com/mine/.`) or when passing
Windows paths (`C:/test/.`), the helper *will* see the dot, and all is
fine.

Unfortunately the behavior of the MSYS2 Bash cannot be altered in that
respect because existing build workflows *depend* on the current behavior.

Please note we did not have that problem previously, as the helper was a
shell script and therefore stayed in the POSIX-emulated realm, no
POSIX->Windows path translation necessary.

Now, we have two tests in t0060 that try to catch changes in this
particular scenario, verifying that only the dots are cut off of paths
like `/a/b/c/.`.

Given that we cannot modify MSYS2 to appease those tests (because we would
break many more important things), and given that you can easily work
around this by using paths native to Windows when using Git interactively
(which the tests cannot do because they target Linux), I am inclined to
change the tests.

Here are the options I see:

A) remove the tests in question

B) mark them as !MINGW instead

C) change just those two tests from using `$PWD` (pseudo-Unix path) to
  `$(pwd)` (native path)

I would like to hear your feedback about your preference, but not without
priming you a little bit by detailing my current opinion on the matter:

While I think B) would be the easiest to read, C) would document the
expected behavior better. A) would feel to me like shrugging, i.e. the
lazy, wrong thing to do.

What do you think?
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]