[fix] Fix the list if symlink is in the same directory

[at-grandpa]

Fix the list if symlink is in the same directory.

test dir

$ pwd
/tmp/ghq_test
$ tree -a -L 3
.
├── main_dir
│   ├── a_dir
│   │   └── .git
│   ├── h_dir -> /tmp/ghq_test/sym_dir/h_dir/
│   └── z_dir
│       └── .git
└── sym_dir
    └── h_dir
        └── .git

9 directories, 0 files

ghq root

$ ghq root
/tmp/ghq_test

test

before (latest version)

$ ghq -v
ghq version 0.12.2 (rev:6e7f3c8)
$ ghq list
main_dir/a_dir
main_dir/h_dir
sym_dir/h_dir

main_dir/z_dir is not found.

after (this PR version)

setup.

$ pwd
/path/to/github.com/at-grandpa/ghq
$ git branch
* fix-list-symlink-in-same-directory
  master
$ make build
go get  -d
go mod tidy
go build  -ldflags="-s -w -X main.revision=360ea7a"

ghq list.

$ ./ghq list
main_dir/a_dir
main_dir/h_dir
main_dir/z_dir
sym_dir/h_dir

main_dir/z_dir is found.

Why?

If filepath.Walk returns filepath.SkipDir at symlink time, it will not reference subsequent files in the same directory. Therefore, it was not output to the list. So I have decided not to return filepath.SkipDir for symlinks.

[Songmu]

Thank you! This is an acceptable change.

However, I think it is better to store whether it is a symlink or not into variable such as isSymlink and return nil or filepath.SkipDir by referring it at the end of the func block, rather than commonizing LocalRepositoryFromFile,

How do you think?

[at-grandpa]

Thank you for your advice.

I was also worried about it. I thought it would be difficult to understand if I increased the new variables, so I chose commonizing LocalRepositoryFromFile.

But the following morning, I thought it was unnecessary commonality. And the return location is in the middle of the func block. So it is difficult to understand.

I find it easier to use isSymlink.

I'll fix it.

[at-grandpa]

Oh..
Travis CI failed...

Go:tip

(snip)

# golang.org/x/xerrors
../../../../pkg/mod/golang.org/x/xerrors@v0.0.0-20190510150013-5403a72a6aaf/adaptor_go1_13.go:16:14: undefined: errors.Frame
../../../../pkg/mod/golang.org/x/xerrors@v0.0.0-20190510150013-5403a72a6aaf/format_go1_13.go:12:18: undefined: errors.Formatter
FAIL	github.com/motemen/ghq [build failed]

(snip)

I don't think it has anything to do with this correction.
Please help me...

[Songmu]

This error is due to the problem that errors.Printer etc. was reverted by the following change, but xerrors haven't followed up with it yet.

golang/go@3e2c522

Since ghq is a tool, not a library, there is no need to keep track of the HEAD of the Go language development.
Could you remove the -tip line in .travis.yml?

[Songmu]

Adjusted on my side and merged.

I'm grad for your contribution. It is a good job, test code is also sufficient.

Thank you!

[at-grandpa]

@Songmu Thank you! I'm glad I could contribute.