Re: [RFC/PATCH] reset: accept "git reset <removed file>"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:

> Makes me wonder
>
>  - if we can/want to have a logic like this inside verify_filename();

Yes, I think so.  I was worried that this would be confusing for some
command that looks to the worktree, like git grep without --cached,
but I suspect that worry was unfounded.

The one case I am worried about is "git rev-parse".  What is
"git rev-parse <path>" supposed to be used for?

>  - if we need a corresponding logic in either the previous else/if cascade
>    that calls verify_non_filename(), or in verify_non_filename() itself.

Yes.

Is it safe to load the index so early?  I can imagine a person trying
"git reset" to recover from a corrupted index; are we regressing in
that respect and how would one check for it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]