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
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
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
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(
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
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 f
6 matches
Mail list logo
