Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"

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

 



On Thu, Sep 11, 2008 at 10:22 AM, Jeff Whiteside
<jeff.m.whiteside@xxxxxxxxx> wrote:
> And if you want to delete all untracked files
>      ls | sed s/`git status --index --filenamesonly`//g | rm
>      ls | sed s/`git status --commitrepo --filenamesonly`//g | rm
>            (I realize those commands don't actually work, but I'm a noob.)

"git clean" (http://www.kernel.org/pub/software/scm/git/docs/git-clean.html)
will delete untracked file.

> So that 'tracked by git' isn't just another ambiguous semantic.

While I can't find where it might be explicitly defined, it does seem
clear that a file/dir is "tracked" as soon as it's added.

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.

- Eric
--
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]

  Powered by Linux