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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.