On Wednesday 2006, November 01 20:49, Junio C Hamano wrote: > >> git-reset [--hard | --mixed] HEAD^ oops/file1 > While that perfect makes sense from mechanical point of view, I > am not sure what it _means_ to keep some paths from now > abandoned future while having some other paths reset to the > rewound commit, from the point of view of end-user operation. Isn't that exactly what the user would be asking for when they are doing a per-file reset? This is a contrived example as git makes it easier to do it in far more sensible ways; but I've done this before now in subversion... What if I want to try out some radical change? It goes like this: x --- y --- z Where x is some stable commit; y is a load of crazy changes; we discover that the crazy changes are all fine except for one, and so want to rollback one file, without yet commiting: git-reset --hard HEAD^ frotz Git would get frotz from HEAD^ and write it to the working directory and the index (or just index with --mixed). > In other words, I do not have a good explanation on what "git > reset [--hard|--mixed] <commit> <path>..." does that I can write > in the documentation. --mixed Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action. If <path> is given then only that path will be reset to the state that <path> had in <commit-ish>. The working tree will be untouched. --hard Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree since <commit-ish> are lost. If <path> is given then only that path will be reset in both the working tree and the index to the state that <path> had in <commit-ish>. > Well, now I am not sure of anything anymore ;-). I do hope I'm not being presumptuous with all the above. I feel a bit gobby spouting off like I know what I'm talking about. Especially as I wrote absolutely no part of git whatsoever :-) Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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