Re: [PATCH v2 08/23] checkout: fix bug with --to and relative HEAD

From: Duy Nguyen <pclouds@gmail.com>
Date: Jul 4, 2015, 02:45 UTC
Message-ID: <CACsJy8C=BZF57GqRxO6CfBAYOxywEd4zHay4cgSZMrKCv6u77w@mail.gmail.com>
In-Reply-To: <1435969052-540-9-git-send-email-sunshine@sunshineco.com>

On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 19 quoted lines

> Given "git checkout --to <path> HEAD~1", the new worktree's HEAD should
> begin life at the current branch's HEAD~1, however, it actually ends up
> at HEAD~2. The happens because:
>
>     1. git-checkout resolves HEAD~1
>
>     2. to satisfy is_git_directory, prepare_linked_worktree() creates a
>        HEAD in the new worktree with the value of the resolved HEAD~1
>
>     3. git-checkout re-invokes itself with the same arguments within the
>        new worktree to populate the worktree
>
>     4. the sub git-checkout resolves HEAD~1 relative to its own HEAD,
>        which is the resolved HEAD~1 from the original invocation,
>        resulting unexpectedly and incorrectly in HEAD~2 (relative to the
>        original)
>
> Fix this by unconditionally assigning the current worktree's HEAD as the
> value of the new worktree's HEAD.

Good catch!

> @@ -924,9 +925,11 @@ static int prepare_linked_checkout(const struct checkout_opts *opts,
>          * value would do because this value will be ignored and
>          * replaced at the next (real) checkout.
>          */

This comment "any valid value would do.. will be ignored" is proved incorrect.

Show 9 quoted lines

> +       if (!resolve_ref_unsafe("HEAD", 0, rev, NULL))
> +               die(_("unable to resolve HEAD"));
>         strbuf_reset(&sb);
>         strbuf_addf(&sb, "%s/HEAD", sb_repo.buf);
> -       write_file(sb.buf, 1, "%s\n", sha1_to_hex(new->commit->object.sha1));
> +       write_file(sb.buf, 1, "%s\n", sha1_to_hex(rev));
>         strbuf_reset(&sb);
>         strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
>         write_file(sb.buf, 1, "../..\n");

-- 
Duy