Breaks when not in toplevel Git directory

[hobzcalvin]

git status | fpp, selecting files, and applying them to git add works fine when I'm at the top level of a Git repo, but not if I enter a subdirectory. It appears to append the selected file to the git repo path, not pwd.

[loganlinn]

came to report this issue too. my use case is also git status

[pcottle]

Can you show the output of your git status command @hobzcalvin ? I believe this might be due to git doing abbreviated file paths which I fixed in #18 (well, at least warned against)

[lefoy]

I have the same issue, I can't open files when I'm not in the toplevel git directory.

[hobzcalvin]

09:11:13@~/test/myrepo/inside> git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    nested/morethings.stuff

nothing added to commit but untracked files present (use "git add" to track)
09:11:15@~/test/myrepo/inside> git status | fpp
executing command:
git add '/Users/grant/test/myrepo/nested/morethings.stuff'
fatal: pathspec '/Users/grant/test/myrepo/nested/morethings.stuff' did not match any files
09:11:26@~/test/myrepo/inside> cd ..
09:11:54@~/test/myrepo> git status | fpp
executing command:
git add '/Users/grant/test/myrepo/inside/nested/morethings.stuff'
09:12:01@~/test/myrepo> git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   inside/nested/morethings.stuff
09:12:07@~/test/myrepo>

[ruslanosipov]

+1, can not edit files with Vim unless I'm in a Git top level directory. Vim receives quoted path string and assumes it to be a new file name.

[pcottle]

Weirdddd since we parse the top level directory for both git and mercurial here:

https://github.com/facebook/PathPicker/blob/master/src/parse.py#L38-L66

@hobzcalvin I can't repro myself -- can you output the result of:

• git --version
• git rev-parse --show-toplevel when inside myrepo/inside
• git rev-parse --show-toplevel when inside of myrepo

? im wondering if our top level dir parsing is not correct

[metavida]

I was able to reproduce this issue locally but only when the selected file was within a sub-folder of the current working directory. See attached screencast.

Here's the output of git status and git status | fpp + ls -l

marcoswk src [master•] $ git status
On branch master
Your branch is up-to-date with 'facebook/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   new/issue20.py
    modified:   test.py

marcoswk src [master•] $ git status | fpp
getting input
executing command:
ls -l '/Users/marcoswk/workspace/PathPicker/new/issue20.py' './test.py'
ls: /Users/marcoswk/workspace/PathPicker/new/issue20.py: No such file or directory
-rw-r--r--@ 1 marcoswk  staff  8238 May 11 21:09 ./test.py

As you can see, for whatever reason, the full path except the src directory is used when selecting the new/issue20.py file.

[alphang]

"I was able to reproduce this issue locally but only when the selected file was within a sub-folder of the current working directory."

This is true for me as well. If I go up to the top level git dir, then it works.
However, if I try it from a subfolder then I can reproduce the issue.

[pcottle]

Gah yeah, this is an issue specific to git status. Heres the relevant block from the manpage:

The paths mentioned in the output, unlike many other Git commands, are made relative to the current directory if you are working in a subdirectory (this is on purpose, to help cutting and pasting). See the status.relativePaths config option below.

Emphasis mine. 😢 😭 You can of course turn this off but who will do that:

If the config variable status.relativePaths is set to false, then all paths shown are relative to the repository root, not to the current directory.

Whereas of course git diff (and a bunch of other git commands) are made relative to the top level tree:

[pcottle:~/Dropbox (Facebook)/wip/PathPicker:master]$ git diff HEAD~2 --stat
 src/colorPrinter.py  |  2 +-
 src/parse.py         | 16 ++++++++--------
 src/processInput.py  |  1 +
 src/screenControl.py |  1 -
 src/test.py          | 10 +++++-----
 5 files changed, 15 insertions(+), 15 deletions(-)
[pcottle:~/Dropbox (Facebook)/wip/PathPicker:master]$ cd src/
[pcottle:~/Dropbox (Facebook)/wip/PathPicker/src:master]$ git diff HEAD~2 --stat
 src/colorPrinter.py  |  2 +-
 src/parse.py         | 16 ++++++++--------
 src/processInput.py  |  1 +
 src/screenControl.py |  1 -
 src/test.py          | 10 +++++-----
 5 files changed, 15 insertions(+), 15 deletions(-)

I feel like we have two options:

1. Dangerously introspect into the format of the piped input and detect if its a git status command, and then totally rework our logic. not ideal
2. use filesystem validation to check for top-level git directory path prepending and, if that fails, switch to ./ and check again.

I'll take a crack at 2. later today, since we need to move in that direction regardless

What if you prepended a sequence of "../" until you had a file match and displayed only paths whose existence was confirmed?

[pcottle]

What if you prepended a sequence of "../" until you had a file match and displayed only paths whose existence was confirmed?

hrm, id rather check either the git level top dir or just the current dir, since going up forever seems a bit cargo-cultish (like killing a fly with a sledgehammer). this is next on my plate though after this release

[pcottle]

This is fixed in #114!!