Re: Bug! Git merge also fails with a wrong error message

[Jeff King <peff@peff.net>]

On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:

> After asking several people who didn't believe me,
> after all I could pass all checks to ensure that
> the file in question really is tracked, despite the error
> message telling it is not. (The file has a history, it is
> part of the branch,
> git status behaves as expected when I rename it, and so on.)

Whether a file in the working tree is tracked or not does not have to do
with the history, but rather with whether it is mentioned in the index.

Does the file appear in "git ls-files"?

It sounds like you are perhaps making changes in the working tree and
index, and then trying to checkout/merge on top of that. In that case
"git status" would report the file as renamed, but it's possible the
file is still in the working tree. From git's perspective the file is no
longer tracked, but the operations you are requesting would overwrite
the new contents (and git is being safe by refusing to do so).

Generally you don't want to merge with uncommitted changes like this.
You would want to commit them and then do your merge.

But even if you do commit, the question still remains: if you have
committed the removal of this file, then why is it still there? Is
something else creating it after you have deleted it?

-Peff