El 6/11/2007, a las 13:48, Pierre Habouzit escribió:
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@xxxxxxxxx> writes:
Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
