Theodore Tso [off-list ref] writes:
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
I don't think "revert-file" is a good name for this: although other
SCM often call this "revert", what Git calls "revert" is about
reverting an existing commit (it's "backout" in hg for example). The
terminology to revert the working tree to the last commited version is
already here in Git, it's "reset".
I've already argued in favor of allowing "git reset --hard <files>",
which is consistant with existing terminology and doesn't add an extra
command, but without success.
--
Matthieu
On Thu, 30 Oct 2008, Matthieu Moy wrote:
I've already argued in favor of allowing "git reset --hard <files>",
which is consistant with existing terminology and doesn't add an extra
command, but without success.
If you have a file argument, the --hard option is redundant, isn't it?
So what about simply "git reset <file>" ?
Nicolas
On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:
On Thu, 30 Oct 2008, Matthieu Moy wrote:
quoted
I've already argued in favor of allowing "git reset --hard <files>",
which is consistant with existing terminology and doesn't add an extra
command, but without success.
If you have a file argument, the --hard option is redundant, isn't it?
So what about simply "git reset <file>" ?
errrrm, git reset <file> resets the index notion of the file to its status
in HEAD... which I'm sure is *somehow* useful to "some" people ;P
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
On Thu, 30 Oct 2008, Pierre Habouzit wrote:
On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:
quoted
On Thu, 30 Oct 2008, Matthieu Moy wrote:
quoted
I've already argued in favor of allowing "git reset --hard <files>",
which is consistant with existing terminology and doesn't add an extra
command, but without success.
If you have a file argument, the --hard option is redundant, isn't it?
So what about simply "git reset <file>" ?
errrrm, git reset <file> resets the index notion of the file to its status
in HEAD... which I'm sure is *somehow* useful to "some" people ;P
Too bad...
Nicolas
On Thu, 2008-10-30 at 13:17 -0400, Nicolas Pitre wrote:
quoted
errrrm, git reset <file> resets the index notion of the file to its status
in HEAD... which I'm sure is *somehow* useful to "some" people ;P
Too bad...
The changes need to not unnecessarily break scripts or let down people's
expectations. I'd be happy to deprecate the use of reset with file
arguments, to keep 'reset' focused on resetting the current HEAD and not
concerned with files; but changing its behaviour on a subtle level like
this is sure to annoy...
Sam.
Hi,
On Thu, Oct 30, 2008 at 9:20 AM, Matthieu Moy [off-list ref] wrote:
Theodore Tso [off-list ref] writes:
quoted
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
I don't think "revert-file" is a good name for this: although other
SCM often call this "revert", what Git calls "revert" is about
reverting an existing commit (it's "backout" in hg for example). The
terminology to revert the working tree to the last commited version is
already here in Git, it's "reset".
git's reset is _not_ the same as svn/bzr/hg's revert; and it's overlap
in functionality is smaller than you realize.
I've already argued in favor of allowing "git reset --hard <files>",
which is consistant with existing terminology and doesn't add an extra
command, but without success.
Such a command would
* delete newly added files instead of simply untracking them.
That's the right thing for reset, but not for a svn/bzr/hg-like revert
(and unfortunately means unintended data loss.)
* doesn't make sense during an incomplete merge, unless you add some
way of specifying which branch users want to revert their files back
to. Aren't there enough confusing flags for reset already? (One
surprisingly common comment I get about eg is that git reset is too
hard to understand and eg reset fixes it -- despite the fact that I
merely renamed two flags and hid the second form of the command.)
* doesn't work for the initial commit
* provides no way to revert files or subdirectories back to their
state at some previous revision (hg and bzr revert have a flag to
provide this; it's not useful all the time but is on occasion) Also,
if users try to modify their command slightly to get such behavior,
say 'git reset --hard REVISION' instead of 'git reset --hard .', then
they're in trouble. (Recoverable, but they need an 'expert' to help
them now.)
Also, there's three different kinds of "undo": switching to an old
revision (git checkout REVISION, or svn/hg update -r, etc.),
forgetting or discarding commits/merges/rebases (git reset), and
modifying files to undo previous modifications without touching HEAD
(svn/bzr/hg revert). Users get confused enough between these
different kinds of undo; overloading them further would be really bad,
IMO.
(Part of the reason for users getting confused between these kinds of
undo is the fact that git doesn't implemented svn/bzr/hg-like revert,
and tends to steer them towards git checkout and git reset, which are
commands typically meant for the *other* kinds of undo.)
Just my $0.02,
Elijah