From: Pierre Habouzit <madcoder@debian.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
Steven Grimm <koreth@midwinter.com>,
git@vger.kernel.org
Subject: Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
Date: Tue, 06 Nov 2007 13:48:33 +0100 [thread overview]
Message-ID: <20071106124833.GA25637@artemis.corp> (raw)
In-Reply-To: <Pine.LNX.4.64.0711061216330.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-11-06 12:48 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-05 19:01 [PATCH] git-revert is one of the most misunderstood command in git, help users out Pierre Habouzit
2007-11-05 19:04 ` Pierre Habouzit
2007-11-05 19:05 ` J. Bruce Fields
2007-11-05 19:10 ` Pierre Habouzit
2007-11-05 19:28 ` Steven Grimm
2007-11-05 19:50 ` Pierre Habouzit
2007-11-05 21:54 ` Alejandro Martinez Ruiz
2007-11-05 22:06 ` David Kastrup
2007-11-05 23:41 ` Alejandro Martinez Ruiz
2007-11-05 22:21 ` Junio C Hamano
2007-11-05 23:40 ` Johannes Schindelin
2007-11-06 0:08 ` Pierre Habouzit
2007-11-06 2:51 ` Junio C Hamano
2007-11-06 3:18 ` Johannes Schindelin
2007-11-06 4:54 ` Junio C Hamano
2007-11-06 8:49 ` Pierre Habouzit
2007-11-06 9:29 ` Mike Hommey
2007-11-06 9:37 ` Pierre Habouzit
2007-11-06 12:32 ` Johannes Schindelin
2007-11-06 18:06 ` Junio C Hamano
2007-11-06 18:27 ` Johannes Schindelin
2007-11-06 19:39 ` Pierre Habouzit
2007-11-06 19:42 ` Junio C Hamano
2007-11-06 22:21 ` Johannes Schindelin
2007-11-06 20:06 ` Robin Rosenberg
2007-11-06 20:13 ` Mike Hommey
2007-11-06 21:21 ` Robin Rosenberg
2007-11-06 22:25 ` Johannes Schindelin
2007-11-07 8:16 ` Mike Hommey
2007-11-07 11:08 ` Johannes Schindelin
2007-11-07 19:32 ` Robin Rosenberg
2007-11-07 20:01 ` Jakub Narebski
2007-11-07 9:03 ` David Kastrup
2007-11-06 11:08 ` Junio C Hamano
2007-11-06 11:51 ` Johannes Sixt
2007-11-06 12:16 ` Johannes Schindelin
2007-11-06 12:25 ` Johannes Schindelin
2007-11-06 12:48 ` Pierre Habouzit [this message]
2007-11-06 17:43 ` Wincent Colaiuta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071106124833.GA25637@artemis.corp \
--to=madcoder@debian.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=koreth@midwinter.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).