Re: files are disappearing in git
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Nov 25, 2005, 22:11 UTC
- Message-ID
- <Pine.LNX.4.64.0511251400570.13959@g5.osdl.org>
- 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