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

Git status deleted and renamed show up for both changes in the working directory and in staging. #1371

Closed
philipbordallo opened this issue Jun 21, 2020 · 2 comments · Fixed by #1411
Labels
🐛 bug Something isn't working as expected.

Comments

@philipbordallo
Copy link

Bug Report

Current Behavior

Git status deleted and renamed symbols show up for both changes in the working directory and for when a file is staged.

Expected Behavior

Git status deleted and renamed symbols show up for when a file is staged.

Additional context/Screenshots

In the documentation, deleted and renamed are both described as being related to when a file is in the staging area. But it looks like deleted and renamed symbols show up regardless of whether they are in staging or the working directory.

Here's an example, given this setup:

example-repo on  release 
❯ tree
.
├── one.txt
└── two.txt

0 directories, 2 files

If I delete one.txt, and rename two.txt to three.txt, I see the deleted and renamed symbols even though the files are part of the working directory.

example-repo on  release [✘»] 
❯ git status --long
On branch release
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	deleted:    one.txt
	deleted:    two.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	three.txt

no changes added to commit (use "git add" and/or "git commit -a")

And adding them to staging, the symbols remain (matching what's stated in the documentation).

example-repo on  release [✘»] 
❯ git status --long
On branch release
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    one.txt -> three.txt
	deleted:    two.txt

Environment

  • Starship version: starship 0.42.0
  • Shell type: zsh
  • Shell version: zsh 5.8
  • Terminal emulator: Terminal.app
  • Operating system: macOS 10.14.6
@philipbordallo philipbordallo added the 🐛 bug Something isn't working as expected. label Jun 21, 2020
@Aelnor
Copy link
Contributor

Aelnor commented Jun 25, 2020

I can try to investigate this one unless someone objects.

@Aelnor
Copy link
Contributor

Aelnor commented Jun 29, 2020

Here's the investigation result.
This behavior is caused by renames_index_to_workdir() option (src/modules/git_status.rs:202)

I'm not sure if Starship needs it, but I've found out it was introduced here (which doesn't help either): https://github.com/starship/starship/pull/247/files

Aelnor added a commit to Aelnor/starship that referenced this issue Jun 29, 2020
This option causes advances rename detection which causes incosistency between `git status` and Starship reports.
Closes starship#1371
Aelnor added a commit to Aelnor/starship that referenced this issue Jun 29, 2020
This option causes advances files rename detection which causes inconsistency between `git status` and Starship reports.
Closes starship#1371
Aelnor added a commit to Aelnor/starship that referenced this issue Jun 29, 2020
This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes starship#1371
Aelnor added a commit to Aelnor/starship that referenced this issue Jun 29, 2020
This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes starship#1371
Aelnor added a commit to Aelnor/starship that referenced this issue Jun 29, 2020
This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes starship#1371
Aelnor added a commit to Aelnor/starship that referenced this issue Jul 13, 2020
This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes starship#1371
andytom pushed a commit that referenced this issue Jul 14, 2020
* Remove renames_index_to_workdir() option from git status

This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes #1371

* add test for manually remaned and deleted files in git_state module

* fix tests
chipbuster pushed a commit to chipbuster/starship that referenced this issue Jan 14, 2021
…hip#1411)

* Remove renames_index_to_workdir() option from git status

This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes starship#1371

* add test for manually remaned and deleted files in git_state module

* fix tests
dagbrown pushed a commit to dagbrown/starship that referenced this issue Oct 22, 2021
…hip#1411)

* Remove renames_index_to_workdir() option from git status

This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes starship#1371

* add test for manually remaned and deleted files in git_state module

* fix tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working as expected.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants