From: Linus Torvalds Date: Fri, 25 Nov 2005 22:11:22 GMT Subject: Re: files are disappearing in git Message-ID: In-Reply-To: <20051125195121.GG16995@mythryan2.michonline.com> On Fri, 25 Nov 2005, Ryan Anderson wrote: > > Can something like this sequence do it? Nope, I don't think that should matter. Also, that doesn't seem to match what Nico & co are doing, but that's hard to tell.. A merge result should be totally independent of the index file(s) involved. A dirty index file can cause a merge to _fail_, in that git may refuse to do the merge at all because of the index not matching the original branch, but a successful automated merge should never have any dependencies on what happens to be in the index at the time the merge was done. So you can think of a merge as being totally specified by the trees involved, unless we have some bug, of course. I can't think of any. Now, what _can_ happen (I think) is that if a merge is a failure (and there, a dirty index can certainly be the _cause_ of that failure), then when you fix it up and commit, there's some mix-up at _that_ stage. For example, let's say that you had a dirty tree or something, and then the merge failed, and you didn't see anything wrong, so you just end up doing a "git commit". At _that_ point, what you had in the index matters very much, of course, since the index is what will be committed. > I think that's the situation where I've personally managed to lose > and/or revert some changes. Hmm.. Can you elaborate? (Side note: all my commentary is purely about the "raw git" interfaces. I don't know what cogito may do on top of it). Linus