Re: [PATCHv4] sha1_file: fix iterating loose alternate objects

From: Jeff King <peff@peff.net>
Date: Feb 2, 2015, 20:02 UTC
Message-ID: <20150202200258.GA28915@peff.net>
In-Reply-To: <xmqqk300t772.fsf@gitster.dls.corp.google.com>

On Mon, Feb 02, 2015 at 12:00:17PM -0800, Junio C Hamano wrote:

Show 26 quoted lines

> Jonathon Mah <me@jonathonmah.com> 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