On Fri, Jan 13, 2012 at 07:49:17PM +0100, Yves Goergen wrote: > On 13.01.2012 18:50 CE(S)T, Jeff King wrote: > > 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. > > I'm not using the index. In fact I don't even know how that what I have > read about it can be useful. Whether you realize it or not, git is using the index to store state. When you "git add", "git rm", or "git mv", it is updating the index. > > Does the file appear in "git ls-files"? > > Yes, it's in the list along with all other files. Then it should be considered tracked, and there's a bug. I notice that in your first mail, you mentioned a problem with "checkout", and in the second one, a problem with "merge". Do you still have the repo around with the "checkout" problem? If so, is the file also in your "git ls-files" output in that repo? It is much more likely to me that there is a bug in the merge than in regular checkout (because merge has many complex corner cases surrounding the 3-way merge, whereas checkout is simply moving from one state to another). I'd like to make sure we're not seeing two different problems. > Here's the git status output: > # On branch master > nothing to commit (working directory clean) > > I have switched to master and the very next action was trying the merge. > There's no change in the working directory, and nothing uncommitted. Which version of git are you using? There were many bugs fixed around this area of merge around the v1.7.7 timeframe. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html