Towards v1.7.3

[Pat Thoyts]

I've done the rebase-merge for git v1.7.3 now and pushed it to our devel branch.

These tests failed:
t3032-merge-recursive-options (new!)
t3509-cherry-pick-merge-df (new!)
t4301-log-line-single-history (new!)
t4302-log-line-merge-history (new!)
t5407-post-rewrite-hook
t5505-remote
t7400-submodule-basic
t7508-status
t7810-grep
t9001-send-email
t9500-gitweb-standalone-no-errors
t9501-gitweb-standalone-http-status
Unfinished tests:
t9200-git-cvsexportcommit

So there are some new ones there and once again they seem to be CRLF
issues. I added the perl CGI.pm package locally which changes the
95*-gitweb tests but I'm not convinced it is worth including
gitweb.cgi support in Git for windows so that is not pushed yet.

[Eric Sunshine]

On 9/23/2010 7:01 AM, Pat Thoyts wrote:
> I've done the rebase-merge for git v1.7.3 now and pushed it to our devel branch.
> These tests failed:
> t3032-merge-recursive-options (new!)

These failures are due to grep and sed undesirably swallowing CR in CRLF
line-endings. I will send a patch for this shortly.

> t3509-cherry-pick-merge-df (new!)

I did not see any obvious CRLF issues here. The problem may be more
subtle, though I have not investigated thoroughly yet.

> t4301-log-line-single-history (new!)
> t4302-log-line-merge-history (new!)

These failures are due to use of '-L /foo/,/bar/' option. I'm still
investigating, but my suspicion is that MSYS is undesirably transforming
-L arguments to C:\foo and C:\bar paths, though they should be left as-is.

-- ES

[Eric Sunshine]

On 9/27/2010 7:47 AM, Eric Sunshine wrote:
> On 9/23/2010 7:01 AM, Pat Thoyts wrote:
>> I've done the rebase-merge for git v1.7.3 now and pushed it to our
>> devel branch.
>> These tests failed:

>> t4301-log-line-single-history (new!)
>> t4302-log-line-merge-history (new!)
>
> These failures are due to use of '-L /foo/,/bar/' option. I'm still
> investigating, but my suspicion is that MSYS is undesirably transforming
> -L arguments to C:\foo and C:\bar paths, though they should be left as-is.

I verified that the problem is indeed MSYS converting the regular
expression /foo/ to path c:/msysgit/foo, however, I am not exactly sure
what to do about the problem, other than disabling the test altogether
for msysgit. The trick of doubling the leading slash only works if no
slashes appear later in the argument. (That is, //foo becomes /foo, but
//foo/ just stays //foo/.)

-- ES

[Johannes Schindelin]

Hi,

Does -L/foo/,/bar/ work (note the missing space)?

Ciao,
Dscho

[Eric Sunshine]

That was one of the first things I tried, and it failed, although I see
now (with debugging output) that it did not fail for the reason I
thought. Eliminating the space before /foo/ actually does fix the
problem for the /foo/ expression, but then the /bar/ expression is
incorrectly turned into path c:/msysgit/bar/. Here is the debugging output:

expecting success:
git log --pretty=format:%s%n%b -L/func/,/^}/ path0 > current-path0

SPEC [/func/,C:/msysgit/^}/]
SPEC [C:/msysgit/^}/]
fatal: -L parameter's argument should be <start>,<end>
not ok - 5 Show the line level log of path0

In this case, SPEC[] is my debugging output. It is the 'spec' argument
passed to parse_loc() in line.c.

-- ES

[Johannes Schindelin]

Hi,

Thanks for trying!

I now agree that these tests should just be disabled on Windows, it is
just too great a hassle to try to work around the issue.

Ciao,
Dscho

[Eric Sunshine]

On 9/27/2010 2:48 PM, Johannes Schindelin wrote:
> On Mon, 27 Sep 2010, Eric Sunshine wrote:
>> On 9/27/2010 2:24 PM, Johannes Schindelin wrote:
>>> On Mon, 27 Sep 2010, Eric Sunshine wrote:
>>>> I verified that the problem is indeed MSYS converting the regular
>>>> expression
>>>> /foo/ to path c:/msysgit/foo, however, I am not exactly sure what to do
>>>> about
>>>> the problem, other than disabling the test altogether for msysgit. The
>>>> trick
>>>> of doubling the leading slash only works if no slashes appear later in the
>>>> argument. (That is, //foo becomes /foo, but //foo/ just stays //foo/.)
>>>
>>> Does -L/foo/,/bar/ work (note the missing space)?
>>
>> That was one of the first things I tried, and it failed, although I see now
>> (with debugging output) that it did not fail for the reason I thought.
>> Eliminating the space before /foo/ actually does fix the problem for the /foo/
>> expression, but then the /bar/ expression is incorrectly turned into path
>> c:/msysgit/bar/.
>

> I now agree that these tests should just be disabled on Windows, it is
> just too great a hassle to try to work around the issue.

A larger issue is that '-L /expr/,/expr/' is not usable for Git for
Windows users under the (default) MSYS shell. This perhaps raises the
question of whether a proposal should be made for git to recognize some
additional character other than '/' for delimiting expressions. (Other
languages and tools often support alternative delimiters, so the idea is
not without precedent.) On the other hand, the issue is strictly the
"fault" of MSYS, so perhaps it makes more sense to "fix" our local MSYS
or propose to the MSYS project an improved mechanism for suppressing
MSYS's default '/foo' transformation.

-- ES