threads / discuss / 47659

cygwin git and golang: how @{u} is handled

Subject: cygwin git and golang: how @{u} is handled

## tl;dr

4 messages between Jan 21, 2018 and Jan 22, 2018.

replies: 3people: 3as markdown or json

John Cheng· Jan 21, 2018, 18:31 UTC · lore

I am experiencing a strange behavior and I'm not certain if it is a problem with golang or the cygwin version of git.

Steps to reproduce: Use golang's os/exec library to execute exec.Command(os.Args[1],"log","@{u}") // where os.Args[1] is either cygwin git or Windows git

Expected result:
commit 09357db3a29909c3498143b0d06989e00f5e2442
Author: John Cheng <johnlicheng@gmail.com>
Date:   Sun Jan 14 10:57:01 2018 -0800
...

Actual result: Suppose that cygwin git is specified, the result becomes: exit status 128 fatal: ambiguous argument '@u': unknown revision or path not in the working tree.

Version: git version 2.15.1.windows.2 git version 2.15.1

I'm not certain if this is a git problem, as I could not reproduce this problem using python to script cygwin git.

A list of scenarios I've tested are
1. golang + cygwin git = "exit code 128"
2. golang + windows git = "exit code 0"
3. python + cygwin git = "exit code 0"
4. python + windows git = "exit code 0"

I've tried to write a simple program to echo the command line parameters passed by go into the process it executes - and it appears that go itself does not change "@{u}" into "@u". I'm a bit stuck at point to figure out which may be the cause: golang or git. I figured I'd start here.

-- 
---
John L Cheng

Ævar Arnfjörð Bjarmason· Jan 21, 2018, 18:55 UTC · re: John Cheng · lore

Re: cygwin git and golang: how @{u} is handled

On Sun, Jan 21 2018, John Cheng jotted:

> Actual result:
> Suppose that cygwin git is specified, the result becomes:
> exit status 128 fatal: ambiguous argument '@u': unknown revision or
> path not in the working tree.

Given that:

    $ git log @{x}
    fatal: ambiguous argument '@{x}': unknown revision or path not in the working tree.

Spews the output back at you as @{x} not @x the problem must be in whatever is passing the argument to git, whether that's go or some other wrapper.

Try putting a "git" first in your $PATH which is nothing but:

    #!/bin/sh
    echo "args: $@"
    exit 1

And seeing what you get.

Philip Oakley· Jan 21, 2018, 23:43 UTC · re: John Cheng · lore

Re: cygwin git and golang: how @{u} is handled

From: "John Cheng" <johnlicheng@gmail.com>

Show 38 quoted lines

>I am experiencing a strange behavior and I'm not certain if it is a
> problem with golang or the cygwin version of git.
>
> Steps to reproduce:
> Use golang's os/exec library to execute
> exec.Command(os.Args[1],"log","@{u}") // where os.Args[1] is either
> cygwin git or Windows git
>
> Expected result:
> commit 09357db3a29909c3498143b0d06989e00f5e2442
> Author: John Cheng <johnlicheng@gmail.com>
> Date:   Sun Jan 14 10:57:01 2018 -0800
> ...
>
> Actual result:
> Suppose that cygwin git is specified, the result becomes:
> exit status 128 fatal: ambiguous argument '@u': unknown revision or
> path not in the working tree.
>
> Version:
> git version 2.15.1.windows.2
> git version 2.15.1
>
> I'm not certain if this is a git problem, as I could not reproduce
> this problem using python to script cygwin git.
>
> A list of scenarios I've tested are
> 1. golang + cygwin git = "exit code 128"
> 2. golang + windows git = "exit code 0"
> 3. python + cygwin git = "exit code 0"
> 4. python + windows git = "exit code 0"
>
> I've tried to write a simple program to echo the command line
> parameters passed by go into the process it executes - and it appears
> that go itself does not change "@{u}" into "@u". I'm a bit stuck at
> point to figure out which may be the cause: golang or git. I figured
> I'd start here.
>

There is a similar problem a user is experiencing on Git-for-Windows, that we/the user haven't got to the bottom of, but it appears to have a similar form where the braces appear to be is some form parsed twice (though thats still a guess / hypothesis).

"Aliases in git are stripping curly-brackets (#1220)" https://github.com/git-for-windows/git/issues/1220#issuecomment-340341336

Philip

John Cheng· Jan 22, 2018, 01:44 UTC · re: Philip Oakley · lore

Re: cygwin git and golang: how @{u} is handled

Hi Phillip,

Thanks for pointing me to the github issue. I've added my comments to it. For my particular issue, it was resolved by setting "CYGWIN=noglob" as an environment variable. Hopefully it resolves Robert's problem as well.

On Sun, Jan 21, 2018 at 3:43 PM, Philip Oakley <philipoakley@iee.org> wrote:

Show 52 quoted lines

> From: "John Cheng" <johnlicheng@gmail.com>
>
>> I am experiencing a strange behavior and I'm not certain if it is a
>> problem with golang or the cygwin version of git.
>>
>> Steps to reproduce:
>> Use golang's os/exec library to execute
>> exec.Command(os.Args[1],"log","@{u}") // where os.Args[1] is either
>> cygwin git or Windows git
>>
>> Expected result:
>> commit 09357db3a29909c3498143b0d06989e00f5e2442
>> Author: John Cheng <johnlicheng@gmail.com>
>> Date:   Sun Jan 14 10:57:01 2018 -0800
>> ...
>>
>> Actual result:
>> Suppose that cygwin git is specified, the result becomes:
>> exit status 128 fatal: ambiguous argument '@u': unknown revision or
>> path not in the working tree.
>>
>> Version:
>> git version 2.15.1.windows.2
>> git version 2.15.1
>>
>> I'm not certain if this is a git problem, as I could not reproduce
>> this problem using python to script cygwin git.
>>
>> A list of scenarios I've tested are
>> 1. golang + cygwin git = "exit code 128"
>> 2. golang + windows git = "exit code 0"
>> 3. python + cygwin git = "exit code 0"
>> 4. python + windows git = "exit code 0"
>>
>> I've tried to write a simple program to echo the command line
>> parameters passed by go into the process it executes - and it appears
>> that go itself does not change "@{u}" into "@u". I'm a bit stuck at
>> point to figure out which may be the cause: golang or git. I figured
>> I'd start here.
>>
> There is a similar problem a user is experiencing on Git-for-Windows, that
> we/the user haven't got to the bottom of, but it appears to have a similar
> form where the braces appear to be is some form parsed twice (though thats
> still a guess / hypothesis).
>
> "Aliases in git are stripping curly-brackets (#1220)"
> https://github.com/git-for-windows/git/issues/1220#issuecomment-340341336
>
>
>
> Philip
>

-- 
---
John L Cheng