2014-06-09 16:04 GMT+02:00 David Kastrup <d...@gnu.org>:
> Pierre-François CLEMENT <lik...@gmail.com> writes:
>> Hi all,
>> Someone pointed out on the "Git for human beings" Google group
>> (https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion)
>> that using git-reset's hard mode when having staged untracked files
>> simply deletes them from the working dir.
>> Since git-reset specifically doesn't touch untracked files, one could
>> expect having staged untracked files reset to their previous
>> "untracked" state rather than being deleted.
>> Could this be a bug or a missing feature? Or if it isn't, can someone
>> explain what we got wrong?
> git reset --keep maybe?
> In a work dir and index without modifications, I expect
> git apply --index ...
> git reset --hard
> to remove any files that git apply created.  It would not do so using
> your proposal.  I agree that it seems a bit of a borderline, but I
> consider it better that once a file _is_ tracked, git reset --hard will
> first physically remove it before untracking it.
> --
> David Kastrup

Hm, I didn't think of "git apply --index"... Makes sense for this
special use, but I'm not sure about the other use cases. Consider this

You create a new (untracked) file.
You use git-reset's hard mode to go one commit back, the new
(untracked) file's still there.
You add/stage that new file.
You use git-reset's hard mode again to go one commit back, and the new
untracked file you just staged gets deleted.

Also, according to Git-scm

"Tracked files are files that were in the last snapshot [...].
Untracked files are everything else."

So it seems to me like staged untracked files shouldn't be considered
as tracked files, and thus shouldn't be removed. Or maybe, git-reset's
hard mode should always delete everything including untracked files?
It would also make sense, given the numerous modes it has.

Pierre-François CLEMENT
Application developer at Upcast Social
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to