From: Ryan Anderson <ryan@michonline.com>
Date: Fri, 25 Nov 2005 19:51:22 GMT
Subject: Re: files are disappearing in git
Message-ID: <20051125195121.GG16995@mythryan2.michonline.com>
In-Reply-To: <Pine.LNX.4.64.0511251022360.13959@g5.osdl.org>

On Fri, Nov 25, 2005 at 11:12:00AM -0800, Linus Torvalds wrote:
> 
> Ok, 
> 
>   Nico gave me private access to the tree, so I quickly cloned it and 
> started bisecting it to figure out where the problem was. I haven't looked 
> at the source code, and all the commit messages seem to be in German 
> (which I can kind of understand if I work at it, but not very well), but 
> it definitely turns out none of that matters.
> 
> The problem is a bad merge. And in fact, that merge lost _more_ than just 
> the three files under Code/Spikes/Statistik/, it also lost a file called 
> Code/lw1/Client/Pics/icon/lw1-icon.png.
> 
> I don't quite see _how_ it lost them. The merge in question is a totally 
> trivial in-index merge, and when I re-do it, I don't lose those files. In 
> this case, all the lost files were from the "other branch" of the merge, 
> and they were new to that branch. IOW, in git-merge-one-file parlance, it 
> is that trivial "added in one" case.

Can something like this sequence do it?

	git-init-db
	git add file1 ; git commit -m "1"
	(cd .. ; git clone tree1 tree2 )
	(cd .. ; git clone tree1 tree3 )
	git add file2 ; git commit -m "2"
	git push ../tree2/
	git add file3 ; git commit -m "3"

	cd ../tree3/
	git add file4
	git commit -m "4"

	cd ../tree2/
	git pull ../tree3/

The key point being that the merge is done in a tree that has its index
out of sync with its HEAD (git push ../tree2/ .... git pull ../tree3/ )

I think that's the situation where I've personally managed to lose
and/or revert some changes.

-- 

Ryan Anderson
  sometimes Pug Majere