Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
- From
- Eric Raible <raible@gmail.com>
- Date
- Sep 11, 2008, 23:49 UTC
- Message-ID
- <279b37b20809111649h77666a46u362dddfa1b40e0ca@mail.gmail.com>
- In-Reply-To
- <20080911233941.GP4829@genesis.frugalware.org>
On Thu, Sep 11, 2008 at 4:39 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
Show 8 quoted lines
> On Thu, Sep 11, 2008 at 02:24:51PM -0700, Eric Raible <raible@gmail.com> wrote: >> My question is why "git reset --hard" can't make a special case for >> _newly added_ tracked files. After all, "git status" knows that they're >> "new files", and "git reset --hard" could realize that wiping them off >> the face of the earth isn't the most helpful thing possible. > > I rarely need this, but I use 'git read-tree -m HEAD' before git reset > --hard in case I want such a behaviour.
What advantages does "git read-tree -m HEAD" have over "git reset" or "git rm --cached <file list>"?