David Kastrup <dak@xxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: > ... >> I don't agree on that point. If the following command is valid >> >> $ git reset --whatever $(git ls-files) >> >> I'd expect it to do the same thing as "git reset --whatever", without >> the file limit. > > Disagree. That's not how git checkout with a file list works, and > whenever the file list is not full, moving HEAD will silently lose > non-listed files "softly". > > Special casing the full list rather than the empty list does not make > sense, either. I think that is a sensible argument. After thinking about it a bit more, I think I misunderstood your suggestion about "reset [--hard] <commit> paths...". If "reset --mixed <commit> paths..." means "reset these index entries without touching work tree" (because that is how --mixed reset without "paths" behaves --- index-only without touching work tree), it makes sense for "reset --hard <commit> paths..." to mean "reset these index entries and work tree". I am however still somewhat in favor of deprecaing "reset --mixed <commit> paths..." and spelling this special case without --mixed, though. - 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
