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

quoted text
> On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html