Re: [PATCHv3] git-fetch: Split fetch and merge logic

From: Junio C Hamano <junkio@cox.net>
Date: Feb 25, 2007, 05:07 UTC
Message-ID: <7vlkimx1t1.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7v1wkfzqgk.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 8 quoted lines

> Santi Béjar <sbejar@gmail.com> writes:
> ...
>> The current merge behaviour is unchanged.
>
> I overlooked your earlier huge testcase patch, but I noticed it
> does not include any test that fetches an annotated tag that
> points at a commit or a non-commit, nor an unannotated tag that
> is a tree or a blob.

A couple of other things I think the users of information in FETCH_HEAD rely on need to be checked by the test suite.

 * Automated following of tags when a branch head is fetched.
   When this happens, I think the users (not just git-pull
   script but end users) expect the branch head to be listed
   first in the FETCH_HEAD file, so that:

	$ git fetch git://some.repo/
	$ git show FETCH_HEAD

   gives stable and useful result.

 * When two refs are listed on the command line explicitly, are
   they listed in the order given by the user in the resulting
   FETCH_HEAD file?

	$ git fetch git://some.repo/ one two
	$ git fetch git://some.repo/ two one

   Again, "git show FETCH_HEAD" after that expects the first one
   to show 'one' and the second one 'two'.  Replacing 'fetch'
   with 'pull' in the example would affect the parent order in
   the resulting Octopus.