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 Wed, Sep 10, 2008 at 8:14 PM, Changsheng Jiang <jiangzuoyan@xxxxxxxxx> wrote:
> I think the current behavior is better than you described. If you want
> to ignore some files, you can added it to the exclude file. All files
> not excluded in the repo directory is maintained by git.

No, there's a limbo state -- the "untracked" files shown by git status
(which is the default state; these are files that have not been
explicitly requested to be ignored or be tracked).  Note the quote
from Linus at the beginning of Eric's email that specifically
references this.

Anyway, Eric wasn't really talking about ignoring files, since he was
explicitly adding them for the next commit.  It's just that at some
point he changed his mind and decided he didn't want to include any of
the changes he had already made in the next commit, but was surprised
when git reset --hard deleted the files from both the index and
working copy instead of just the index.  git reset --hard really is
meant for throwing away unwanted stuff (particularly including in the
working directory), but I can see how he may have expected behavior
more along the lines of git rm --cached for those particular files.  I
don't agree with that viewpoint (I see files as tracked as soon as you
stage it, not once you commit it), but I can see where the expectation
comes from.

Just my thoughts,
Elijah
--
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