From: Philip Oakley Date: Sun, 21 Jan 2018 23:43:28 GMT Subject: Re: cygwin git and golang: how @{u} is handled Message-ID: <0A3A0675F3984789908D19A7A39235D5@PhilipOakley> 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