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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alex Riesen <raa.lkml@xxxxxxxxx> writes:

> On Fri, Nov 20, 2009 at 11:46, Junio C Hamano <gitster@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]