From: Eric Sunshine <sunshine@sunshineco.com>
Date: Sat, 04 Jul 2015 08:49:12 GMT
Subject: Re: [PATCH v2 08/23] checkout: fix bug with --to and relative HEAD
Message-ID: <CAPig+cSQ6K7noQiKJbwHpY4tO2hzQMH9q-0nqkWUX_ecJkCTEg@mail.gmail.com>
In-Reply-To: <CACsJy8C=BZF57GqRxO6CfBAYOxywEd4zHay4cgSZMrKCv6u77w@mail.gmail.com>

On Fri, Jul 3, 2015 at 10:45 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> 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.

Yup, and I meant to update the comment but promptly forgot about it.
Thanks for the reminder.