Bug: Git index has all-zero entries when updating HEAD@git

mlcui-corp commented 1 month ago

Description

When updating HEAD@git, such as by jj newing a change that has a different tree than @-, the changed entries in the Git index get set to all-zeroes.

This affects shell prompts which use romkatv/gitstatus, such as romkatv/powerlevel10k.

I have confirmed this also occurred before a075a5c6cabd493759fc973d99d3fd88feb74735.

Steps to Reproduce the Problem

Create a new empty working copy change in a colocated repository.
jj new to another change, which changes files.
Observe the Git index for the changed files has its cache entry set to an all-zero entry.

Example

``` ~/git/jj @3090adfd ❯ jj log -r "main::wz | @" @ lpom mlcui@google.com 2024-05-30 10:29:18 75ad │ (empty) (no description set) │ ○ wzzo mlcui@google.com 2024-05-30 10:02:28 10da ├─╯ test index update ◆ sqww martinvonz@google.com 2024-05-29 23:54:30 main* HEAD@git 3090 │ repo: consider empty and undescribed merge commits as discardable ~ ~/git/jj @3090adfd ❯ jj show -s wz Commit ID: 10da93209b109ca8789a5e5af511a6fad635ec10 Change ID: wzzoqkqrstsxxxztxupwyquwntktqsuo Author: mlcui (2024-05-29 17:10:32) Committer: mlcui (2024-05-30 10:02:28) test index update M cli/src/cli_util.rs M lib/src/git.rs ~/git/jj @3090adfd ❯ git status HEAD detached at 3090adfd5 nothing to commit, working tree clean ~/git/jj @3090adfd ❯ jj new wz Working copy now at: oolo e29f (empty) (no description set) Parent commit : wzzo 10da test index update Added 0 files, modified 2 files, removed 0 files ~/git/jj @10da9320 !2 ❯ git ls-files --debug > /tmp/status1 ~/git/jj @10da9320 !2 ❯ git update-index --refresh ~/git/jj @10da9320 ❯ git ls-files --debug > /tmp/status2 ~/git/jj @10da9320 ❯ git diff --no-index /tmp/status1 /tmp/status2 | cat diff --git a/tmp/status1 b/tmp/status2 index 5dbd5e9f3..4c5c417dd 100644 --- a/tmp/status1 +++ b/tmp/status2 @@ -203,11 +203,11 @@ cli/src/cleanup_guard.rs uid: 763389 gid: 89939 size: 3689 flags: 0 cli/src/cli_util.rs - ctime: 0:0 - mtime: 0:0 - dev: 0 ino: 0 - uid: 0 gid: 0 - size: 0 flags: 0 + ctime: 1717029073:8506810 + mtime: 1717029073:8506810 + dev: 64769 ino: 89036716 + uid: 763389 gid: 89939 + size: 113163 flags: 0 cli/src/command_error.rs ctime: 1716961666:917815566 mtime: 1716961666:917815566 @@ -1607,11 +1607,11 @@ lib/src/fsmonitor.rs uid: 763389 gid: 89939 size: 9656 flags: 0 lib/src/git.rs - ctime: 0:0 - mtime: 0:0 - dev: 0 ino: 0 - uid: 0 gid: 0 - size: 0 flags: 0 + ctime: 1717029073:8506810 + mtime: 1717029073:8506810 + dev: 64769 ino: 89036551 + uid: 763389 gid: 89939 + size: 68592 flags: 0 lib/src/git_backend.rs ctime: 1716782322:588232367 mtime: 1716782322:588232367 ```

Expected Behavior

Running git update-index --refresh or git status after a jj new does not update the index.

Actual Behavior

Running git update-index --refresh or git status after a jj new updates the index as some entries are all-zero.

Specifications

Platform: gLinux, based on Debian Testing.
Version: 3090adfd5c4042c422c60760a22ed555aa6acc9e (main as of writing) and b31f75bc94c4552454ab929b54b9f37340231fac (before a075a5c6cabd493759fc973d99d3fd88feb74735 was committed)

martinvonz commented 1 month ago

This was a fun reminder of a patch I sent to the Git mailing list a long time ago to make git reset --mixed not refresh the index. That was rejected because although porcelain commands should refresh the index themselves, scripts might expect the index to already be refreshed after running (the porcelain command) git reset. So I think we should do that too.

Can you check if #3787 helps?

mlcui-corp commented 1 month ago

Unfortunately it does not :/

$ jj new push-qlxtorvultuy@origin
$ git ls-files --debug | grep "ctime: 0"
  ctime: 0:0

martinvonz commented 1 month ago

Unfortunately it does not :/

Not surprising. As Yuya commented on the PR the method I found was not the method I was looking for :(

martinvonz / jj