Re: Re* Bug report: reset -p HEAD
Jeff King writes: > 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. Thanks; makes sense after twisting my mind somewhat, exactly for the reason you stated here ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re* Bug report: reset -p HEAD
Sorry about the regression and thanks for report and fixes. On Thu, Oct 24, 2013 at 9:24 PM, Jeff King wrote: > On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote: > >> Maarten de Vries 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re* Bug report: reset -p HEAD
On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote: > Maarten de Vries 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: 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. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re* Bug report: reset -p HEAD
Maarten de Vries 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); } /* git reset tree [--] paths... can be used to -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report: reset -p HEAD
Some more info: It used to work as intended. Using a bisect shows it has been broken by commit 166ec2e9. Kinds regards, Maarten de Vries On 25 October 2013 01:05, Maarten de Vries wrote: > Hi, > > I noticed that reset -p HEAD is inconsistent with checkout -p HEAD. > When running checkout -p you are asked to discard hunks from the index > and worktree, but when running reset -p you are asked to apply hunks > to the index. It would make more sense if reset -p asked to discard > (reversed) hunks from the index. > > Digging a bit further, it looks like reset -p is actually intended to > show hunks to discard when resetting to HEAD. The > git-add--interactive.perl script has different cases for resetting to > the head and for resetting to anything else. However, builtin/reset.c > always passes a hash to run_add_interactive, even if HEAD is provided > explicitly on the command line or no revision is given. As a result, > the special case for resetting to the HEAD is never triggered and > git-add--interactive.perl always asks to apply hunks rather than > discard the reverse hunks. > > The offending part in builtin/reset.c is on line 307. It's the bit > with sha1_to_hex(sha1): >> 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); >> } > > I'm not familiar enough with the git source, but it's probably a > fairly trivial fix for someone who is. > > > Kind regards, > Maarten de Vries > > > P.S. > > This bit in git-add--interactive.perl convinced me that resetting to > HEAD interactively should be handled separately: >> 'reset_head' => { >> DIFF => 'diff-index -p --cached', >> APPLY => sub { apply_patch 'apply -R --cached', @_; }, >> APPLY_CHECK => 'apply -R --cached', >> VERB => 'Unstage', >> TARGET => '', >> PARTICIPLE => 'unstaging', >> FILTER => 'index-only', >> IS_REVERSE => 1, >> }, >> 'reset_nothead' => { >> DIFF => 'diff-index -R -p --cached', >> APPLY => sub { apply_patch 'apply --cached', @_; }, >> APPLY_CHECK => 'apply --cached', >> VERB => 'Apply', >> TARGET => ' to index', >> PARTICIPLE => 'applying', >> FILTER => 'index-only', >> IS_REVERSE => 0, >> }, -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Bug report: reset -p HEAD
Hi, I noticed that reset -p HEAD is inconsistent with checkout -p HEAD. When running checkout -p you are asked to discard hunks from the index and worktree, but when running reset -p you are asked to apply hunks to the index. It would make more sense if reset -p asked to discard (reversed) hunks from the index. Digging a bit further, it looks like reset -p is actually intended to show hunks to discard when resetting to HEAD. The git-add--interactive.perl script has different cases for resetting to the head and for resetting to anything else. However, builtin/reset.c always passes a hash to run_add_interactive, even if HEAD is provided explicitly on the command line or no revision is given. As a result, the special case for resetting to the HEAD is never triggered and git-add--interactive.perl always asks to apply hunks rather than discard the reverse hunks. The offending part in builtin/reset.c is on line 307. It's the bit with sha1_to_hex(sha1): > 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); > } I'm not familiar enough with the git source, but it's probably a fairly trivial fix for someone who is. Kind regards, Maarten de Vries P.S. This bit in git-add--interactive.perl convinced me that resetting to HEAD interactively should be handled separately: > 'reset_head' => { > DIFF => 'diff-index -p --cached', > APPLY => sub { apply_patch 'apply -R --cached', @_; }, > APPLY_CHECK => 'apply -R --cached', > VERB => 'Unstage', > TARGET => '', > PARTICIPLE => 'unstaging', > FILTER => 'index-only', > IS_REVERSE => 1, > }, > 'reset_nothead' => { > DIFF => 'diff-index -R -p --cached', > APPLY => sub { apply_patch 'apply --cached', @_; }, > APPLY_CHECK => 'apply --cached', > VERB => 'Apply', > TARGET => ' to index', > PARTICIPLE => 'applying', > FILTER => 'index-only', > IS_REVERSE => 0, > }, -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html