Re: [RFC/PATCHv8 00/10] git notes

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 19, 2010, 18:10 UTC
Message-ID: <7vk4ve9dad.fsf@alter.siamese.dyndns.org>
In-Reply-To: <81b0412b1001190754m37ed01b0nd93b318d77d88a75@mail.gmail.com>

Alex Riesen <raa.lkml@gmail.com> writes:

Show 13 quoted lines

> On Fri, Nov 20, 2009 at 11:46, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -716,7 +719,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
>>                if (!strcmp(arg, "-"))
>>                        arg = "@{-1}";
>>
>> -               if (get_sha1(arg, rev)) {
>> +               if (get_sha1_mb(arg, rev)) {
>>                        if (has_dash_dash)          /* case (1) */
>>                                die("invalid reference: %s", arg);
>>                        if (!patch_mode &&
>
> This is a bit of a problem on Windows, as the arg (eventually containing
> something like "master..."), will be passed to resolve_ref below.

I don't see "resolve_ref below"; do you mean this part?

		/* we can't end up being in (2) anymore, eat the argument */
		argv++;
		argc--;

		new.name = arg;
		if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
			setup_branch_path(&new);
			if (resolve_ref(new.path, rev, 1, NULL))
				new.commit = lookup_commit_reference(rev);
			else
				new.path = NULL;
			parse_commit(new.commit);
			source_tree = new.commit->tree;
		} else
			source_tree = parse_tree_indirect(rev);

It is primarily to tell "git checkout master" and "git checkout master^0" apart (the latter must detach HEAD). IOW, it is testing if you gave the "name" of the branch, or something that yields the commit object name that happens to be at the tip of the branch. So the call to resolve_ref() is very relevant.

> Now, Windows,
> being the piece of shit it is, will lie and tell that a file
> "refs/heads/master..."
> exists and be same as "refs/heads/master".

Meh; then windows users cannot use "git checkout A..." syntax (they can still use "git checkout A...HEAD", I presume).

This is not a problem specific to three-dots, but if you give the function "refs/heads/master.." it would also get "exists" back, no? You could teach resolve_ref() about windows (namely, the filesystem may lie about anything that ends with a series of dots).

> This breaks "checkout to merge base" on Windows and t2012 in particular.

> BTW, why should the arg be run through resolve_ref at all if
> get_sha1(_mb) has succeeded?
> Isn't the commit already resolved by lookup_commit_reference_gently?

l-c-r-g makes sure rev (that is raw object name SHA-1) points at a commit and doesn't have anything to do with the name.