[Bug]: staging/unstaging cause problems with .gitignore and/or file deletion

[229c9cf0]

Describe the bug

The automatic backup tries to manually enumerate and add all files. If some of these files are listed in the .gitignore, that will abort with an error message instead of only adding tracked and new files.

Further, this causes git to never record file deletions, since nonexistent files will never be matched by the file glob expansion.

Relevant errors (if available)

VM229:15026 git obsidian error: The following paths are ignored by one of your .gitignore files:
~CHANGES.md
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"

VM229:78 Uncaught (in promise) Error: The following paths are ignored by one of your .gitignore files:
~CHANGES.md
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"

    at Object.action (eval at <anonymous> (app.js:1), <anonymous>:2120:29)
    at PluginStore.exec (eval at <anonymous> (app.js:1), <anonymous>:2155:29)
    at eval (eval at <anonymous> (app.js:1), <anonymous>:2594:43)
    at new Promise (<anonymous>)
    at GitExecutorChain.handleTaskData (eval at <anonymous> (app.js:1), <anonymous>:2592:16)
    at GitExecutorChain.eval (eval at <anonymous> (app.js:1), <anonymous>:2576:44)
    at Generator.next (<anonymous>)
    at fulfilled (eval at <anonymous> (app.js:1), <anonymous>:2496:28)
    at processTicksAndRejections (internal/process/task_queues.js:93)
GitError @ VM229:78
action @ VM229:2120
exec @ VM229:2155
eval @ VM229:2594
handleTaskData @ VM229:2592
eval @ VM229:2576
fulfilled @ VM229:2496
processTicksAndRejections @ internal/process/task_queues.js:93
Promise.then (async)
processTicksAndRejections @ internal/process/task_queues.js:93
VM229:15020 git obsidian message: Everything is up-to-date

Steps to reproduce

1. add a file to .gitignore (best use a file in the vault root directory, not sure if deeper levels also fail)
2. change something in that file
3. wait for the automatic backup, observe the error popup

and concerning deletion

1. delete a file, edit a different file to make the backup trigger eventually
2. wait for the automatic backup, observe that the deletion wasn't recorded (either in the source control view or manually by git status)

Expected Behavior

All changes are recorded and committed, the presence of ignored files shouldn't interfere.

Addition context

The submodule path uses git add -A, not sure why this isn't also used for the normal path. (That should avoid both problems.)

Same problem of using globs instead of built-in selectors also appears in other places, at least in stageAll in the same way, and unstageAll just below (just a git reset with no arguments should achieve exactly the intended "unstage all" effect.)

Operating system

Windows

[Vinzent03]

You are right that using git add -A is probably better than a glob pattern, but I can't reproduce your issues. Staging deleted files works flawlessly.

That should avoid both problems.

Have you tried staging all files via git add -A from command line?

[229c9cf0]

git add -A on the command line works fine, but either pushing the 'stage all' button or waiting for the automatic backup ignores deletions or renames: (This is Foo --> Bar, plus an automatically triggered link rename.)

After manual git add -A:

[229c9cf0]

Just in case there's a thing that matters in there, here's the .obsidian/plugins/obsidian-git/data.json config file:

{
  "commitMessage": "autocommit {{hostname}} +{{numFiles}} @ {{date}}",
  "commitDateFormat": "YYYY-MM-DDTHH:mm:ss",
  "autoSaveInterval": 5,
  "autoPullInterval": 60,
  "autoPullOnBoot": true,
  "disablePush": false,
  "pullBeforePush": true,
  "disablePopups": false,
  "listChangedFilesInMessageBody": false,
  "showStatusBar": true,
  "updateSubmodules": false,
  "syncMethod": "merge",
  "gitPath": "C:\\Users\\redacted\\AppData\\Local\\Microsoft\\WindowsApps\\git.cmd",
  "customMessageOnAutoBackup": false,
  "autoBackupAfterFileChange": true,
  "treeStructure": false
}

The only thing that might plausibly have an influence is if you have submodule handling enabled (because that will indeed do a git add -A before running the glob version.)

[Vinzent03]

I think that's strange. (I don't have submodules enabled) I don't know what's different/wrong on your end, because I expect more/earlier issues from other users. Will "fix" that nevertheless.

[229c9cf0]

Ah just noticed why it might not always affect others: If things are in (non-hidden) subdirectories, then deletions / renames work fine. (Because the ./* glob matches the top-level directories that still exist.) But for

• files in the root directory
• files in hidden directories in the root directory

the glob fails. That would explain why noone else has complained yet.