Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.

El 6/11/2007, a las 13:48, Pierre Habouzit escribió:

On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:

quoted

Hi,

On Tue, 6 Nov 2007, Junio C Hamano wrote:

quoted

Junio C Hamano [off-list ref] writes:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

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.

Allowing people to revert or cherry pick partially by using
paths limiter is a very good idea; ...

As Pierre said earlier, a partial revert via "revert <commit> --
<paths>" and a partial cherry-pick would make quite a lot of
sense, and in addition, it should not be too hard to add.

Yes, but Pierre also said earlier that people want to revert their  
local
changes.  And the logical thing to try that really is

	git revert <path>

Now, if you read that out in English, it does not make too much  
sense:
"revert the path" (not "revert the _changes_ to that file").  But  
it is
what people try to do.

However, IIUC another thing Pierre mentioned is that

	$scm revert <commit> <path>

commonly means "revert the file _to the version_ stored in <commit>".
This is just different enough from "revert the _changes_ to that file
stored in <commit>" to bite people, no?

 Yeah but that's what checkout is for. The main source of iritation  
for
new users comes (IMHO) from svn, where `svn revert path/to/file` is  
part
of the workflow: in case of a conflict when you `svn up`, you have
either to:
 (1) fix the conflict and `svn resolved path/to/file`
 (2) drop your changes and take the trunk version `svn revert path/ 
to/file`

People really expect git revert -- path/to/file to do the same as git
checkout HEAD -- path/to/file. Though I believe that like I said,  
maybe
we don't wan't git revert -- path/to/file to become the first class
command to do that, but rather to do what the user meant, hinting  
him in
the direction of the proper command. I wasn't really advocating that
git-revert should be a complete implementation of what git checkout
<comitish> -- <paths> does. YMMV.

I agree; they're semantically different and it wouldn't be a good  
thing to start blurring the lines between them too much. It's just  
unfortunate that the term "revert" is used by most other SCMs to mean  
something different than what it means in "git-revert". I think the  
best path here is education, what Pierre says, rather than changing  
git-revert's semantics.

The other changes discussed so far in this thread (path-limiting git- 
revert with preserving its semantics) seem like a good thing.

Cheers,
Wincent