From: "John Cheng" <johnlich...@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 <johnlich...@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
