isomorphic-git: Running `git.add` on removed file throws an error

I am using the React Native example and have noticed issues with trying to run git.add to a file that’s been removed. Instead of adding it to the staged files that’ve been changed, I get a NotFoundError.

image

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 5
  • Comments: 18 (17 by maintainers)

Commits related to this issue

Most upvoted comments

Some notes for myself, as I continue to debug this:

And, sure enough… When I run the relevant commands, they act the way I would “”“expect”“” them to, now understanding the Git implementation a bit better:

const git = require('isomorphic-git');
const fs = require('fs');
const http = require('isomorphic-git/http/web');
const fetch = require('node-fetch');
globalThis.fetch = fetch;

const path = require('path');
const currPath = path.resolve('./')


git.remove({fs, dir: currPath, filepath: 'package.json'}).then(() => console.log("DONE"))

// Once this is ran, it stages 'package.json'

git.resetIndex({fs, dir: currPath, filepath: 'package.json'}).then(() => console.log("DONE"))

// Once this is ran, it unstages 'package.json'

So I guess here’s my question: Should this edgecase be handed by isomorphic-git or by the clients?

The commands are techincally correct in their behavior, but the documentation for these commands infer that they would otherwise handle these edgecases:

remove - Remove a file from the git index (aka staging area)

add - Add a file to the git index (aka staging area)

As far as I see it, we should either update the documentation for these two commands and add a reference to this particular issue, or we should update the code for these commands and invisibly handle these edgecases. I’d be happy to make a PR to solve this problem and write tests confirming their behavior change if you’d like to go down the “handle edgecase” route. What do you think @wmhilton ?

Edit: Another note is that statusMatrix behaves perfectly when dealing with removed files being marked as staged vs unstaged. I’d argue that this advocates even further for us handling the git add edgecase in the library

You can see how I’ve implemented git add in my Git Web Terminal: https://github.com/jcubic/git/blob/gh-pages/js/main.js#L884

The issue with my code is that it doesn’t support git add . but it would be easy to add you only need to list all files like (the first branch in 889) but it should use the same code as in else that allow deleting all commands (here there is only delete a single file).

@linonetwo . is the directory and the isomorphic-git filepath is not recursive. You will need to use a glob pattern library if you want to remove all files. And not git.add() but git.delete().

But if I already delete the file using fs.delete, do I still need git.delete({ dir, filepath: '.', fs }); to delete it?

And I think since file is already deleted by 3rd party program, use a glob pattern library won’t be able to find the deleted file…

Maybe using dugite is the better choise for circumstance where file will gets deleted?

How to commit all delete-file?

await add({ dir, filepath: '.', fs });

This seems not able to add all deletion. Running git add . in terminal actually add those chagnes.

@Nils-Kolvenbach you’ve convinced me that I should just open a PR instead of waiting for further discussion. It’s clear from the documentation (and our confusion) that this is a bug, not a feature.

In the meantime, you can sidestep this issue by using:

git.remove

To stage a deleted file and:

git.resetIndex

To unstage a deleted file. I’m doing this for my app (https://github.com/crutchcorn/GitShark/) and it works perfectly.

I’ll make a notice when the PR is made live