I deleted some files, and they show in the Pull Request as deleted(please see the image below)

How can I NOT have the files in the Pull Request? (also not as deleted)

CodePudding user response：

I don't need them as they're automatically generated. they're in .gitignore

If they were previously tracked, your PR records the fact they are no longer tracked (hence the deletion), and ignored (git check-ignore -v -- a/generated/file should return an "ignore" rule locally)

In other words, this is expected.

CodePudding user response：

In Git, every commit is a full snapshot of every file.

More precisely, every commit holds a full snapshot. Whatever files are in it, those are the files.

There's no such thing as a difference between a commit. A commit is a single collection of files, plus some metadata. So asking for the difference between a commit is like asking for the difference between the Statue of Liberty.

Now, we can ask about the difference between, say, the Statue of Liberty and the Statue of George Washington in the financial district of NYC. Or, more sensibly perhaps, we can ask about the difference between the statue of George Washington in the financial district, and the one in Union Square. But we had to pick two things to ask about. The same is true with commits: we can't ask about the difference without picking two commits.

That's what a pull request does, though. When you use GitHub to make a Pull Request—PRs are a GitHub feature, not a Git feature—GitHub picks two commits to compare. The diff you see is the result of comparing those two commits. One of the two commits is the tip commit of your branch; the other is a commit in what GitHub calls the base branch. (Since Git doesn't have this, we have to do something a bit different in Git, but we can get the same effect there.)

If the PR says that these files are deleted, that means:

• The file does exist in the base commit.
• The file does not exist in the pull-request-branch-tip commit.

If you want the files not to be deleted, you must make a new branch-tip commit in which those files do exist. Then they won't be "deleted". They will instead be in that commit.

Now, once you make some commit, that commit can never be changed. So you can't alter the existing branch-tip commit in your PR. But you don't need to do that. A branch name, in Git, always means the latest commit on this branch. If you add more commits, they're now the latest commit(s). So you can add a new commit to the branch that puts the files back. Now the branch tip commit has the files. Or, you can strip the commit off the branch. This is a bit harder: Git is built to add commits, not strip them away. (Stripping them off the tip of a branch doesn't remove the commits either: it just makes the branch name locate some earlier commit.)

All of these alternatives are wrong for your case

You said in a comment that—and I'm paraphrasing a bit here—these files should not be in commits as they are automatically generated.

Now, the fact is, they are in some commits. This fact is unchangeable, because those commits cannot be changed. You can at most stop using those commits, either leaving them in so as not to damage your commit history, or stripping them away so as to make them so hard to find that nobody will use them (damaging the history on purpose, in other words). Leave the files out of the new commits.

Any PR will show these as deleted because they are deleted by comparison. That is, a git checkout or git switch --detach to the old commit extracts the files: they are in the old commit. A subsequent git checkout or git switch to the newer commit will then remove the files.

Since they're automatically generated, removing them is harmless. (If it's not harmless, they're not properly automatically generated and perhaps they should not be removed.)

Removing the files and committing is probably the right thing to do, and it will show up as a removal, which is also correct. Just live with that. Listing the files in .gitignore afterwards will help make sure that they don't appear in future commits, but does have a minor drawback or two. You probably won't run into it.

If generating the files automatically is very slow, consider adding some special commits on a special branch that does have them, that gets them updated now and then as needed, and allowing people to run git restore branch -- path/to/generated/files. This branch can contain only the generated files, since people will use git restore to populate their working tree (and not their index / staging-area).

CodePudding user response：

If those files are important for your repository, it would make sense that they are listed in a pull request when they are added, deleted, modified. If you don't want that, it may imply that your files aren't that important, then you can add them to .gitignore file.