无法 git 拉取：在 ff4e1bf（最新 ec2 实例列表）中删除文件并在 HEAD 中修改。 文件的版本 HEAD 留在树中

Question

I tried to delete a file in my git repo, and now I can't do a git pull anymore.

The file I'm trying to delete is: aws_scripts/source_files/aws_accounts_list/aws_accounts_list.csv

Now when I do a git pull, I get:

CONFLICT (modify/delete): aws_scripts/source_files/aws_accounts_list/aws_accounts_list.csv deleted in ff4e1bf (Latest ec2 instance list.) and modified in HEAD. Version HEAD of aws_scripts/source_files/aws_accounts_list/aws_accounts_list.csv left in tree.

The full error says:

 git pull origin develop
From github.com:bluethundr/jf_cloud_scripts
 * branch            develop    -> FETCH_HEAD
error: could not apply ff4e1bf... Latest ec2 instance list.
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply ff4e1bf... Latest ec2 instance list.
CONFLICT (modify/delete): aws_scripts/source_files/aws_accounts_list/aws_accounts_list.csv deleted in ff4e1bf (Latest ec2 instance list.) and modified in HEAD. Version HEAD of aws_scripts/source_files/aws_accounts_list/aws_accounts_list.csv left in tree.
Auto-merging aws_scripts/python/aws_tools/ec2_mongo.py

How can I make git realize the file is supposed to be deleted and do the git pull I need?

Answer 1

This sort of thing is why I encourage those new to Git to avoid git pull : the pull command is a convenience command that combines two other Git commands.

The base commands are:

• git fetch , meaning obtain new commits from someone else , followed by
• the second command: combine the work I did in my repository with my new commits, with the work they did in their repository with their new commits .

It's true that the first step—the git fetch —is not very useful on its own, because getting their commits is equivalent to just getting a bunch of packages delivered. Until you open them up and use what's in them , they just sit around. So you do need two steps. But I think it's better, for various reasons, to do them on your own at first. (Not everyone agrees with me.)

The second command is where things can get sticky. You choose which second command to use: the default is git merge , but you can (and, based on messages above, did) select git rebase instead. Either method means combine my work with their work; the difference is how the combining is done:

• git merge combines everything in one step, leaving all the original commits untouched. Since history, in Git, is commits, this preserves exactly what you did, and exactly what they did.

• git rebase has the effect of copying your earlier commits to different, new-and-one-hopes-improved, commits. Your Git then abandons your original commits in favor of these new and?improved? commits. Since history, in Git, is the commits in the repository, this leaves you with a more-readable history. It's kind of a fake history though: it implies that you did your work after they did theirs, rather than in parallel with theirs.

There are some strong reasons to prefer one or the other in some cases. In your particular case, probably none of those reasons apply, so either method is fine.

Now, the actual problem here is that during the merge-or-rebase, Git has come across the following situation:

• You removed a file entirely.
• They changed the file.

Git isn't sure how to combine these actions. Perhaps you want to keep the changed file, or just the lines they put in and remove all the other lines. Perhaps you want the file to stay removed. Git isn't willing to pick one answer on its own. So, it stops in the middle of the operation.

Your job is to finish the operation. There are a lot of details, but probably you just want to keep the file gone. To do that, tell Git keep the file gone by removing it and git add ing the result, or using git rm on the file (which I find easier to remember, and has the same effect, but sometimes generates a mild complaint). Then tell Git to continue the operation, whatever it was.

In your particular case, the operation is a rebase, so to continue it after resolving the conflict, run:

git rebase --continue

This will go on to copy any additional commits if needed. Each step can have its own merge conflict (this is one reason some prefer the merge method); if so, you may have to resolve multiple conflicts over multiple commits.

If the second step had been git merge , you would need git merge --continue to continue the merge operation. (In truly ancient versions of Git, there is no --continue here and you must run git commit instead, but unless you work with really old Git versions you are unlikely to encounter this.)

Once the second operation is all done, your git pull is finished.