Andy Parkins <andyparkins@xxxxxxxxx> writes: > 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 I assume when you do the following operation your .git/HEAD points at 'y' which is already committed, and 'z' does not exist yet (it does not come into the scenario you describe below). > 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). You forgot to mention at the same time it makes .git/HEAD point at 'x'. That's the part I am not so sure about. Ah (lightbulb goes on). So after the above reset, you would do a "git commit" with or without -a to create a fixed-up 'y' that does not have changes to 'frotz'? Then it sort of makes sense. --soft with paths specifier does not make much sense (paths specifier is a no-op in that case because --soft does not touch index nor working tree), but I wonder what workflow --mixed would help. It resets the index for frotz from 'x', while your crazy changes of 'y' is still in the working tree. You can "git commit" without -a to create the same fixed-up 'y' that does not have changes to 'frotz', and then keep working on 'y' to make it into less crazy. Ok, that workflow certainly makes sense. >> 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>. That's the "mechanical point of view only" description I was afraid of having. While I think I now see why they can be useful, we would need to extend the examples section to demonstrate how they help workflows to readers. - 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