Re: Re* Bug report: reset -p HEAD

2013-10-25 Thread Junio C Hamano
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 pa

Re: Re* Bug report: reset -p HEAD

2013-10-24 Thread Martin von Zweigbergk
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

Re: Re* Bug report: reset -p HEAD

2013-10-24 Thread Jeff King
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

Re* Bug report: reset -p HEAD

2013-10-24 Thread Junio C Hamano
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(

Re: Bug report: reset -p HEAD

2013-10-24 Thread Maarten de Vries
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