Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.gitignore resolution is inconsistent with `git status` #59

Closed
dorian-marchal opened this issue Sep 1, 2019 · 7 comments

Comments

@dorian-marchal
Copy link

commented Sep 1, 2019

Under specific conditions, gitstatusd and git status do not resolve .gitignore the same way.

Here is an example: https://github.com/dorian-marchal/gitstatus-issue-59

cd /tmp
git clone https://github.com/dorian-marchal/gitstatus-issue-59
cd gitstatus-issue-59

mkdir foo
touch foo/bar
touch foo/baz

. ~/gitstatus/gitstatus.plugin.sh

gitstatus_start -e -d 99

gitstatus_query

git status # Reports a new foo/ dir.
git status --untracked-files # Reports two new foo/{bar,baz} files.

echo $VCS_STATUS_NUM_UNTRACKED # 0
echo $VCS_STATUS_HAS_UNTRACKED # 0
@dorian-marchal

This comment has been minimized.

Copy link
Author

commented Sep 1, 2019

This is not an important issue for me, but I thought you should know.

I noticed it when I wanted to index a new dot file in my home repo, with this .gitignore:

# Ignore everything...
*

# ...except some dot files.
!/.gitconfig
!/.gitignore
!/.bashrc
!/.psqlrc
!/.tmux.conf
!/.vimrc
!/.ssh/
!/.ssh/config # <- Here.

For now, I can simply disable gitstatusd when I'm working on this repo.

@romkatv

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

Thanks for the bug report.

I'm using libgit2 to filter out ignored files. This part of libgit2 is riddled with bugs and is terribly inefficient. The amount of time I spent patching it could've been used to roll my own implementation from scratch several times over. Oh well. Maybe someday.

I've fixed the bug that was affecting your test case, and another one that I noticed during my own testing. I haven't released the new binaries though. You can either wait for the next release (not soon) or build gitstatusd yourself (it's fairly easy).

P.S.

You can simplify your dotfiles .gitignore and incidentally implement a workaround for the bug in gitstatusd. Put * in it and nothing else. To add new files, use git add -f path/to/file. I used to do this with my own dotfiles and it worked great. .gitignore is used only by git add and for filtering untracked files and for nothing else. So even with the blanket * in .gitignore you'll still see added/modified/deleted/etc files. I used to think that having ignored files in the index is somehow bad, but while implementing gitstatusd I learned that it isn't.

Another approach is to not have .gitignore in dotfiles at all and suppressed untracked files with git config --local status.showUntrackedFiles no. This is what I'm using right now with my own dotfiles. The advantage is that you don't need to pass -f to git add and that you can still display untracked files in some directory if you want to: git status -u ~/.ssh.

@dorian-marchal

This comment has been minimized.

Copy link
Author

commented Sep 2, 2019

Thanks 👍

The amount of time I spent patching it could've been used to roll my own implementation from scratch several times over.

Out of curiosity, do you submit your patches upstream?

P.S.

Thanks, that's good to know, your second approach seems great. 👌

@romkatv

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

Out of curiosity, do you submit your patches upstream?

Not anymore. My patches from several months ago are still stuck in limbo, so I don't consider it worth my or anyone else's time to send patches to libgit2.

@dorian-marchal

This comment has been minimized.

Copy link
Author

commented Sep 2, 2019

That's sad. Too bad all maintainers aren't like you. 😉

@romkatv

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

For the sake of context, gitstatusd started as a simple binary that used libgit2 for everything Git-related. Over time I reimplemented all parts that have non-trivial contribution to latency, so that nowadays if you look at CPU profile of gitstatusd there is virtually no libgit2. This makes gitstatusd 40-something times faster than libgit2. Some things are still done via libgit2, and these are the worst parts of gitstatusd both in terms of performance and correctness. If I were starting over I would cut that dependency altogether. I also wouldn't commit compiled binaries to Git -- this stupid design decision constraints my ability to release new binaries, as they cause repository size bloat for all users.

@romkatv

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

For the reference, I linked to my test cases and the bug fix on the existing libgit2 issue: libgit2/libgit2#3535 (comment). If libgit2 devs or users find this useful, they can cherry pick.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.