On Mon, Nov 05, 2007 at 11:40:46PM +0000, Johannes Schindelin wrote: > Hi, > > On Mon, 5 Nov 2007, Junio C Hamano wrote: > > > Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > > > > > But that suggested command is not going to convince anyone they were > > > wrong about git being hard to learn. I wonder if instead of saying, "I > > > know what you meant, but I'm going to make you type a different > > > command," we should make git revert just do what the user meant. > > > > > > There is already precedent for that kind of mixed-mode UI: > > > > > > git checkout my-branch > > > vs. > > > git checkout my/source/file.c > > > > That's an example of mixed-mode UI, but what you are suggesting is quite > > different, isn't it? > > > > There is no other officially supported single-command-way to > > checkout paths out of the index. > > Okay, let's step back a bit. > > We taught "git show" to show other objects than commits, by doing the > obvious things. So there _is_ a precendent to changing a commands > behaviour to accept more than just commits. And there was already another > command for the same purpose, cat-file, which was never meant as > porcelain however. > > Now, what does "revert" _mean_? At the moment, it wants a commit, and > will undo the changes that commit introduced, _and commits it_ (asking > for a message). > > What would I expect "git revert -- file" to do? It would undo the changes > to that file -- and since no commit was specified, I would expect it to > look at the changes against the index. (IOW exactly what Steven > proposed.) > > To continue the analogy, it would have to commit the undoing of the > change. But since that change never was committed, I think it is more > natural to _not_ commit it. > > In the same way, I would expect "git revert <commit> -- file" to undo the > changes in that commit to _that_ file (something like "git merge-file > file <commit>:file <commit>^:file"), but this time commit it, since it > was committed at one stage. I agree that this is something that really makes sense to me, and does not looks like a perversion of the UI, and quite a nice extension in fact. And it would _finally_ solve the issue that for _ANYTHING_ on the planet that I've used for more than 10 seconds, $SCM revert path/to/file reverts local changes :) When you look at how git-revert is implemented, you'll see that it uses the very same code as git cherry-pick does, and in fact, I've wanted a git cherry-pick <commit> -- path1 path2 path3 for a _very_ long time, and your proposal would just gracefully give it as a bonus I believe (of course uncommited changes have no sense for a cherry-pick). I like it a lot. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpvIXNTX8Vlc.pgp
Description: PGP signature
