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

[John Cheng]

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 <philipoak...@iee.org> wrote:
> 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
>



-- 
---
John L Cheng

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

[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 <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.





-- 
---
John L Cheng

Re: Misleading documentation for git-diff-files (diff-filter)

[John Cheng]

Thanks for the clarification! I also didn't realize that diff-files -R
will show added files. You learn something new everyday ;)

On Thu, Jan 4, 2018 at 11:09 AM, Junio C Hamano  wrote:
> Jeff King  writes:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index 9d1586b956..743af97b06 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -469,6 +469,12 @@ ifndef::git-format-patch[]
>>  +
>>  Also, these upper-case letters can be downcased to exclude.  E.g.
>>  `--diff-filter=ad` excludes added and deleted paths.
>> ++
>> +Note that not all diffs can feature all types. For instance, diffs
>> +from the index to the working tree can never have Added entries
>> +(because the set of paths included in the diff is limited by what is in
>> +the index).  Similarly, copied and renamed entries cannot appear if
>> +detection for those types is disabled.
>
> Makes sense; thanks.



-- 
---
John L Cheng

Re: Misleading documentation for git-diff-files (diff-filter)

[John Cheng]

To be clear, I don't mean to imply that diff-files should include
files that are not the index. I was trying to say that as a user, the
documentation gave me a different impression.

For background, my intent was to have a script to look for local git
repos that with unstaged changes. After some trial and error, I found
that git-ls-files gave me what I needed. However, I wanted to point
out why I initially believed git-diff-files with show "added files".
Think of this more as user feedback.

On Wed, Jan 3, 2018 at 3:53 PM, Junio C Hamano <gits...@pobox.com> wrote:
> John Cheng <johnlich...@gmail.com> writes:
>
>> I wanted to know if git diff-files shows files that are not in the
>> index but are in the working tree.
>
> At least in the original design of Git, that would fundamentally be
> impossible, as Git _only_ cares about paths that are in the index,
> so a new file won't be in the picture until it is added.  Because a
> change is shown as "A"dded by the diff family of commands only when
> the old side lacks a path that appears in the new side, there is no
> way "diff-files" that compares the index and the working tree would
> see a path that is missing from the old (i.e. the index) side.



-- 
---
John L Cheng

Misleading documentation for git-diff-files (diff-filter)

[John Cheng]

I originally asked this question on stackoverflow
(https://stackoverflow.com/q/48039277).

I wanted to know if git diff-files shows files that are not in the
index but are in the working tree. The documentation says you can
supply --diff-filter=A, which will select file "that are added".
However, git-diff-files (appears) to never show any files with the
status of "A".

It seems like the cause is that git diff-files includes
diff-options.txt which uses a standard template for --diff-filter
which includes the "A" option. Perhaps a clarification can be added?

Compares the files in the working tree and the index.  When paths
are specified, compares only those named paths.  Otherwise all
entries in the index are compared.  The output format is the
same as for 'git diff-index' and 'git diff-tree'. Files not in the index are
not compared.





-- 
---
John L Cheng