# cygwin git and golang: how @{u} is handled 4 messages from 2018-01-21 to 2018-01-22. Participants: John Cheng, Ævar Arnfjörð Bjarmason, Philip Oakley. Thread: https://gitlist.dev/t/47659 ## John Cheng, 2018-01-21 18:31 Subject: cygwin git and golang: how @{u} is handled Message-ID: URL: https://gitlist.dev/e/CAJzZBAQuOqwRmBLOdUEVMY74_xT2dWe3a%2B9qT9ufc4bp8gjgig%40mail.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 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, 2018-01-21 18:55 Subject: Re: cygwin git and golang: how @{u} is handled Message-ID: <87372zhwiw.fsf@evledraar.gmail.com> URL: https://gitlist.dev/e/87372zhwiw.fsf%40evledraar.gmail.com In-Reply-To: ``` 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, 2018-01-21 23:43 Subject: Re: cygwin git and golang: how @{u} is handled Message-ID: <0A3A0675F3984789908D19A7A39235D5@PhilipOakley> URL: https://gitlist.dev/e/0A3A0675F3984789908D19A7A39235D5%40PhilipOakley In-Reply-To: ``` From: "John Cheng" >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 > 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, 2018-01-22 01:44 Subject: Re: cygwin git and golang: how @{u} is handled Message-ID: URL: https://gitlist.dev/e/CAJzZBARW3Cm_uF24NZOXdoT3dC0t%3DUh3GCxa34_B6uK%3DtJ%2BdsQ%40mail.gmail.com In-Reply-To: <0A3A0675F3984789908D19A7A39235D5@PhilipOakley> ``` 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 wrote: > From: "John Cheng" > >> 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 >> 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 ```