Nguyen Thai Ngoc Duy wrote: > On 11/1/06, Junio C Hamano <junkio@xxxxxxx> wrote: >> I think at the UI level, the most appropriate place would be >> "git reset". Checkout is a Porcelainish that is primarily about >> working tree and it updates the index as a side effect (from the >> UI point of view); you can update the working tree without >> modifying index or you can update both index and the working >> tree, but updating only index and not working tree does not >> belong there. > > Then perhaps git-reset should do "co HEAD path" too if --index is not specified? > To sum up: > - git reset HEAD path -> git checkout HEAD path > - git reset --index HEAD path -> git-ls-files HEAD path|git > update-index --index-info > - git reset HEAD (without path) -> the current behaviour > > Because <commit-ish> may be missing, there is some ambiguation here. Currently "git reset --soft <commit-ish>" updates current head only, "git reset <commit-ish>" is "git reset --mixed <commit-ish>" and updates head and index, and "git reset --hard <commit-ish>" updates head, index and working tree. The same should be the case for "git reset [--soft|--mixed|--hard] [<commit-ish>] [--] [paths...]", with the exception that it wouldn't never update current head. (So --soft with pathspec wouldn't make sense). On the other hand git-reset is mainly about resetting current head, so perhaps git-reset isn't the best place to update fragments of index from HEAD branch. -- Jakub Narebski ShadeHawk on #git Poland - 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