Re: Re* Bug report: reset -p HEAD

[Martin von Zweigbergk <martinvonz@gmail.com>]

Sorry about the regression and thanks for report and fixes.

On Thu, Oct 24, 2013 at 9:24 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
>
>> Maarten de Vries <maarten@de-vri.es> writes:
>>
>> > Some more info: It used to work as intended. Using a bisect shows it
>> > has been broken by commit 166ec2e9.
>>
>> Thanks.
>>
>> A knee-jerk change without thinking what side-effect it has for you
>> to try out.
>>
>>  builtin/reset.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/builtin/reset.c b/builtin/reset.c
>> index f2f9d55..a3088d9 100644
>> --- a/builtin/reset.c
>> +++ b/builtin/reset.c
>> @@ -304,7 +304,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
>>       if (patch_mode) {
>>               if (reset_type != NONE)
>>                       die(_("--patch is incompatible with --{hard,mixed,soft}"));
>> -             return run_add_interactive(sha1_to_hex(sha1), "--patch=reset", &pathspec);
>> +             return run_add_interactive(
>> +                     (unborn || strcmp(rev, "HEAD"))
>> +                     ? sha1_to_hex(sha1)
>> +                     : "HEAD", "--patch=reset", &pathspec);
>>       }
>
> I think that's the correct fix for the regression.  You are restoring
> the original, pre-166ec2e9 behavior for just the HEAD case. I do not
> think add--interactive does any other magic between a symbolic rev and
> its sha1, except for recognizing HEAD specially. However, if you wanted
> to minimize the potential impact of 166ec2e9, you could pass the sha1
> _only_ in the unborn case, like this:

Plus, the end result is more readable, IMHO.

> diff --git a/builtin/reset.c b/builtin/reset.c
> index f2f9d55..bfdd8d3 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -283,6 +283,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
>         if (unborn) {
>                 /* reset on unborn branch: treat as reset to empty tree */
>                 hashcpy(sha1, EMPTY_TREE_SHA1_BIN);
> +               rev = EMPTY_TREE_SHA1_HEX;
>         } else if (!pathspec.nr) {
>                 struct commit *commit;
>                 if (get_sha1_committish(rev, sha1))
> @@ -304,7 +305,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
>         if (patch_mode) {
>                 if (reset_type != NONE)
>                         die(_("--patch is incompatible with --{hard,mixed,soft}"));
> -               return run_add_interactive(sha1_to_hex(sha1), "--patch=reset", &pathspec);
> +               return run_add_interactive(rev, "--patch=reset", &pathspec);
>         }
>
>         /* git reset tree [--] paths... can be used to
>
> That fixes any possible regression from add--interactive treating the
> two cases differently. On an unborn branch, we will still say "apply
> this hunk" rather than "unstage this hunk". That's not a regression,
> because it simply didn't work before, but it's not ideal. To fix that,
> we need to somehow tell add--interactive "this is HEAD, but use the
> empty tree because it's unborn". I can think of a few simple-ish ways:
>
>   1. Pass the head/not-head flag as a separate option.
>
>   2. Pass HEAD even in the unborn case; teach add--interactive to
>      convert an unborn HEAD to the empty tree.
>
>   3. Teach add--interactive to recognize the empty tree sha1 as an
>      "unstage" path.
>
> I kind of like (3). At first glance, it is wrong; we will also treat
> "git reset -p $(git hash-object -t tree /dev/null)" as if "HEAD" had
> been passed. But if you are explicitly passing the empty tree like that,
> I think saying "unstage" makes a lot of sense.

Makes sense to me. I'm sure others can implement that much faster than
I can, but I feel a little guilty, so I'm happy to do it if no one
else wants to, as long as we agree this is the way we want to go.