On Mon, Feb 02, 2015 at 12:00:17PM -0800, Junio C Hamano wrote: > Jonathon Mah <[email protected]> writes: > > > +test_expect_success 'prune: handle alternate object database' ' > > + test_create_repo A && > > + (cd A && > > + echo "Hello World" >file1 && > > + git add file1 && > > + git commit -m "Initial commit" file1) && > > + git clone -s A B && > > + (cd B && > > + echo "foo bar" >file2 && > > + git add file2 && > > + git commit -m "next commit" file2 && > > + git prune) > > +' > > The issue does not have much to do with introducing new path to the > cloned repository, or the original having any specific content for > that matter, so I am tempted to simplify the above to something like > this intead: > > test_create_repo A && > git -C A commit --allow-empty -m "initial commit" && > git clone --shared A B && > git -C B commit --allow-empty -m "next commit" && > git -C B prune
Yeah, I'd agree that more clearly demonstrates the issue (I didn't check that it actually triggers the failure, but presumably you did). I think we could also construct a more elaborate example where we fail to pick up an unreachable segment of history based on the mtime of a tip commit found only in the alternate (whereas this is only testing that we don't bungle the alternate filename so completely that prune barfs). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
