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

Incorrect git status #1428

Closed
xiaoxipang opened this issue Jun 1, 2021 · 22 comments
Closed

Incorrect git status #1428

xiaoxipang opened this issue Jun 1, 2021 · 22 comments

Comments

@xiaoxipang
Copy link

xiaoxipang commented Jun 1, 2021

Thanks for this gorgeous theme and easy-to-use configure command!

I pull a repo from my organization and see several errors when I use them:

  1. After I cloned the repo, I immediately check the status with git status, the message show

    On branch master
    Your branch is up to date with 'origin/master'.
    
    nothing to commit, working tree clean
    

    However, the git status show this:
    image

  2. Then when I try to create a new branch, the git status doesn't show at all
    image

On the other hand, I tried to create a new folder in my local and everything works fine
image

It looks like something is off in that special repo, though I have no clue what params will impact the git status display?
Any suggestions for the investigation point, like a specific file in .git folder I should look into that my impact the VCS_STATUS_NUM_STAGED or even the whole git status prompt section?

System: MacOS Big Sur Version 11.4

@romkatv
Copy link
Owner

romkatv commented Jun 1, 2021

Please do the following:

  1. Run GITSTATUS_LOG_LEVEL=DEBUG zsh
  2. cd into the git repository that's missing git status in prompt.
  3. Run less $GITSTATUS_DAEMON_LOG_POWERLEVEL9K and look at the end for errors.

If you see "unsupported extension name" in there, look at the name of the extension. If it's related to sparse checkouts, see #816 (comment). If it's not related to sparse checkouts, please let me know the name of the extension. Either way, if the extension is not crucial for your workflow, try disabling it.

@xiaoxipang
Copy link
Author

xiaoxipang commented Jun 1, 2021

@romkatv Thanks for the instruction
I'm using the oh-my-zsh, so I'm not sure if I did it correctly. I added the GITSTATUS_LOG_LEVEL=DEBUG in my .zshrc
Then I cd into the repo and checked the log and found no error relating to extension. Though there are some error:
image
Then I switched to master branch and got these logs
image

Is the .git folder broken? Or a problem with the theme?

Again, when I use git status in both branches, it showed nothing to commit, working tree clean

BTW, I forgot to mention:
I tried to switch my zsh theme back to robbyrussell, then there is no problem for both master branch and newly create test branch
image

@romkatv
Copy link
Owner

romkatv commented Jun 2, 2021

Please attach (or send me by email) /Users/<REDACTED>/.git/packed-refs.

@xiaoxipang
Copy link
Author

@romkatv
Thanks for the quick reply again! I thought I resolved it after you pointed me to the packed-refs. I did a quick try on different repos and the above issue only happened on huge repos with more than 200 branches.
I ran the git pack-refs --all for the problematic repos and now it shows git status correctly in my local branches.

@romkatv
Copy link
Owner

romkatv commented Jun 2, 2021

Damn :-( Now I won't be able to fix the bug. Is it perchance possible you can recover the problematic packed-refs?

@xiaoxipang
Copy link
Author

xiaoxipang commented Jun 2, 2021

Don't worry, it is only a temporary fix. When I re-cloned the same repo, it had the same exact problem. And I found a public repo to reproduce the problem: https://github.com/Shopify/ruby
Let me know if it is working or not.

@romkatv
Copy link
Owner

romkatv commented Jun 2, 2021

Here's what I've tried:

git clone https://github.com/Shopify/ruby.git
cd ruby

Once I ran these commands, I've got "master" in prompt (as expected).

What happens if you run these commands? Do you get "master" in prompt? If not, could you send me packed-refs that you get, plus the output of locale, git --version and git config --global -l?

romkatv added a commit that referenced this issue Jun 10, 2021
96b520b2 build v1.5.1 binaries for all platforms
ffeb0507 bump version to v1.5.1
1bcbea07 mbuild: disable pacman upgrades on msys
39dbb92f log a warning if unable to parse packed-refs
a9d70ec0 add `-r` flag to gitstatus_start in bash bindings (#241)
abbf9a79 don't use static_assert with one argument as it's not available prior to c++17 (#239)
f8c396e4 drop all tags if packed-refs doesn't have a header line (#1428)

git-subtree-dir: gitstatus
git-subtree-split: 96b520b248ca872646e27b3df4535898356e4637
romkatv added a commit to romkatv/libgit2 that referenced this issue Jun 11, 2021
If packed-refs is not sorted, refs/tags can preceed refs/heads. We
definitely want to read the latter, so we cannot stop parsing early.

I don't know how but some users manage to create packed-refs that's
not sorted. Moreover, they manage to place refs/heads/master into
packed-refs. See romkatv/powerlevel10k#1428.
romkatv added a commit to romkatv/gitstatus that referenced this issue Jun 11, 2021
@romkatv
Copy link
Owner

romkatv commented Jun 11, 2021

Thanks for sending a clone of the public ruby repo from your machine. This allowed me to track down the bug.

The issue was caused by an unusual but valid format of your local repository. Firstly, there is no .git/refs/heads/master and the reference is encoded in .git/packed-refs. This on its own wouldn't break gitstatusd if .git/packed-refs were sorted but it isn't. I wonder how you managed to create a repository of this kind.

I've fixed the bug but haven't released a new version of gitstatusd yet. I was delaying the previous release in the hope that I would incorporate this fix in it but gave up waiting yesterday before you sent me your local ruby repo. This will now have to wait for the next release. There is no ETA.

In the meantime you can run git pack-refs to create a regular-looking repository. This will allow gitstatusd to do its job and will also make git faster.

delanym pushed a commit to delanym/gitstatus that referenced this issue Jun 16, 2021
delanym pushed a commit to delanym/gitstatus that referenced this issue Jun 16, 2021
@Jmennius
Copy link

Hi there, it looks like I have a similar issue.
This happens in a worktree of the repo (doesn't happen in the repo itself).
Can I try somehow a fixed version?

P.S. Thanks for your awesome work!

@romkatv
Copy link
Owner

romkatv commented Jun 23, 2021

Hi there, it looks like I have a similar issue.
This happens in a worktree of the repo (doesn't happen in the repo itself).

Doesn't sound like the same issue.

Can I try somehow a fixed version?

git clone the gitstatus repo and build gitstatusd. Instructions are in the readme.

@Jmennius
Copy link

Hi there, it looks like I have a similar issue.
This happens in a worktree of the repo (doesn't happen in the repo itself).

Doesn't sound like the same issue.

Yeah, likely... there is also a submodule and although git status doesn't report anything - git submodule does (and I only have a single file reported as unstaged).
Sorry for the noise, most likely my issue (although confusing).

@romkatv
Copy link
Owner

romkatv commented Jun 23, 2021

gitstatus uses the equivalent of git status --ignore-submodules=dirty. Does that this command show anything?

You can look at the gitstatusd log to see which file is reported as changed. See #1428 (comment)

@Jmennius
Copy link

gitstatus uses the equivalent of git status --ignore-submodules=dirty. Does that this command show anything?

You can look at the gitstatusd log to see which file is reported as changed. See #1428 (comment)

TLDR It was a git submodule configuration issue, please disregard.

The .gitmodules configuration was broken (I've moved the submodule in the repository and changed remotes a few days ago - something went wrong apparently).
git submodule would report status for one path and an error for another fatal: no submodule mapping found in .gitmodules for path '<path>', git status was silent (?).
I've tried using broken .gitmodules again to check what git status --ignore-submodules=dirty would report but couldn't reproduce the issue.

@romkatv
Copy link
Owner

romkatv commented Jun 23, 2021

Thanks for the update. I'm glad you've sorted it out.

romkatv added a commit that referenced this issue Jun 27, 2021
76182238 add zwc make target
ea398d90 update libgit2 ref (#1428)

git-subtree-dir: gitstatus
git-subtree-split: 7618223859f614a76ed8019f1a60ee3df18984cf
@toby-griffiths
Copy link

toby-griffiths commented Jul 5, 2021

I'm experiencing this issue on my repo as well. I have a single submodule that is initialise inside the repo. Neither the main repo, nor the submodule have any changes, however Powerline10k is reporting 1 unstaged file & 1 untracked file.

I've tried running the git pack-refs --all command, but it didn't help.

Running these steps…

  1. Run GITSTATUS_LOG_LEVEL=DEBUG zsh
  2. cd into the git repository that's missing git status in prompt.
  3. Run less $GITSTATUS_DAEMON_LOG_POWERLEVEL9K and look at the end for errors.

… I saw no errors reported, however it looks like it could be an issue with the case of a filename, since the same file is mentioned as both unstaged, and untracked, and it's a file we recently corrected the case (from peopleController.php to PeopleController.php).

If I clone the repo down into a new directory then the status is reported correctly.

Also of note, the directory that this local clone was originally setup on was a case-insensitive drive, however I've just rebuilt my laptop with a case-sensitive drive, and restored the backup, so not sure if that has caused the issue?

@romkatv
Copy link
Owner

romkatv commented Jul 5, 2021

@toby-griffiths Doesn't sound like the same issue. As a workaround you can manually fix the case of the file in your repo.

mv peopleController.php tmp && mv tmp PeopleController.php

@romkatv
Copy link
Owner

romkatv commented Jul 5, 2021

Also of note, the directory that this local clone was originally setup on was a case-insensitive drive, however I've just rebuilt my laptop with a case-sensitive drive

In this case I highly recommend re-cloning your repo. git remembers whether your fs is case-sensitive or not when you clone.

@toby-griffiths
Copy link

@romkatv Thank you for the advice. I appreciate not the same, but thought the info might be relevant. Apologies if you would have preferred this as a separate issue.

And thanks for the tip. I will re-clone my repos now.

@romkatv
Copy link
Owner

romkatv commented Jul 5, 2021

I'm going to close this issue to avoid getting more unrelated issues reported via comments (already got two). As I mentioned earlier, the original issue has been fixed but I haven't released a new version of gitstatusd yet and there is no ETA for the next release (I won't do a release just for this fix).

@romkatv romkatv closed this as completed Jul 5, 2021
@toby-griffiths
Copy link

Sorry, for reference, the file in the normal file structure was the correct case all along. I just thing Git had it remembered as with its previous file name case.

Interestingly, renaming the file & committing, then renaming back & committing does not resolve the issue, which I thought it might.

@igbanam
Copy link

igbanam commented Apr 17, 2023

If you're still facing this issue for large git repos, add this to your git config

[index]
  skipHash = false

Or simply run

git config --global index.skipHash false

@romkatv
Copy link
Owner

romkatv commented Apr 17, 2023

@igbanam That's not the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants