Frédéric Brière wrote: > I stumbled on this problem yesterday, working in a sparse checkout of > linux-next.
First of all, thanks for reporting this and sorry to take so long to get back to you. > # See how the non-conflicting file is still in the index? > git status > > # And see how reset --hard does not touch it, but --mixed does? > git reset --hard > git status > git reset --mixed > git status It seems that "read-tree --reset -u" should be somehow taught to imply the effect of "read-tree --reset" (without -u). Duy: does that seem reasonable? Are there any subtleties I should expect to run into? Currently the former uses sparse checkout to limit its effect while the latter operates on the entire index. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
