Re: Re* Bug report: reset -p HEAD
Jeff King p...@peff.net 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: 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 maar...@de-vri.es 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
Re* Bug report: reset -p HEAD
Maarten de Vries maar...@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);
}
/* 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: Re* Bug report: reset -p HEAD
On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
Maarten de Vries maar...@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:
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: 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 p...@peff.net wrote:
On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
Maarten de Vries maar...@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.
--
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
