confusing - "revert" != "git revert"

[GoogleCodeExporter]

confusingly, "revert" in tortoisegit is something quite different than "git 
revert". in tortoisegit it appears to be "git checkout 
<commit> — <filename>" (throw away local changes and check out a specific 
commit) while an actual "git revert" creates a reverse commit designed to 
reverse a bad commit that has already been pushed public.

from http://www.kernel.org/pub/software/scm/git/docs/git-revert.html

"Note: git revert is used to record some new commits to reverse the effect of 
some earlier commits (often only a faulty one). If you want to throw away all 
uncommitted changes in your working directory, you should see git-reset(1), 
particularly the --hard option. If you want to extract specific files as they 
were in another commit, you should see git-checkout(1), specifically the git 
checkout <commit> — <filename> syntax. Take care with these alternatives 
as both will discard uncommitted changes in your working directory."

i think "Revert to this version" needs to read "Checkout this version"

Leon

Original issue reported on code.google.com by leeon...@gmail.com on 2 Dec 2010 at 10:36

[GoogleCodeExporter]

a warning about local changes being discarded (if any exist) would be good, too.

Original comment by leeon...@gmail.com on 2 Dec 2010 at 10:39

[GoogleCodeExporter]

"revert to" is coming from SVN concept. 
That means revert the select files to special version.

"Revert OF" is "git revert". 

I think "git checkout version -- file" is not easy to understand except git 
expert.

git provide too much functions at "git checkout"
Personally, I think git checkout should be used for "switch branch" only.

Anyways, it make sense to provide "warning", at least copy working copy to 
file.keep.

Original comment by lzn...@gmail.com on 3 Dec 2010 at 2:24

• Changed state: Discuss

[GoogleCodeExporter]

there are lots of SVN-sounding terms that actually are not equivalent because 
git is fundamentally different from SVN in workflow and i would not expect 
SVN-ers to just start using git by downloading TortoiseGit without reading 
about how git works and what the terms mean.

though i am not familiar with SVN, i know that pretty much every function that 
"sounds" the same is not and/or does not work identically to SVN. while i agree 
that "revert" makes a lot more linguistic sense as SVN uses it, i disagree with 
using "pull", "push", "merge" as Git uses them, and using "revert" as SVN does, 
considering there is an actual "git revert" that does something very different.

if you were to map every term to its SVN equivalent, trying to hide git 
terminology, you would end up with fetch = "check", pull = update, push = 
commit, commit/stash = "save", merge = ?, checkout = switch, etc.

i'm not sure what the stated goal of TortoiseGit is, but my opinion is you 
should keep all terms consistent with git or not at all. it creates confusion 
for people who know the difference and will screw up those trying to learn and 
then end up running a "git revert" accidentally through bash, thinking it does 
what tortoise and SVN do.

my $0.02

Original comment by leeon...@gmail.com on 3 Dec 2010 at 3:13

[GoogleCodeExporter]

Tortoisegit is based on tortoiseSVN.

Many version control concept are the same regardless git or SVN.

The current solution is, 
If new concept such as pull, fetch, use git concept.

Some common operation, such as switch branch, we use both. like 
'switch\checkout to branch'.

Our purpose is make user know what tgit do when they read menu name, such 
"reset head to this commit".

The word "Revert" is confuse itself. 
Revert can mean revert local change
Revert can mean revert change from this version.
Revert can mean revert change of this version.

So we use long sentence to show what to do.   

"Revert to this commit"
"Revert change by this commit"  that is equal with git revert

Compare "Revert to this version" with "Checkout this version"
which one is easy understand if you never use git before?

Or you can provide a word replace "Revert". That word doesn't confuse SVN and 
git user.

Original comment by lzn...@gmail.com on 3 Dec 2010 at 9:18

[GoogleCodeExporter]

Here is my perspective as a recent convert to Git from SVN (still evaluating 
TortoiseGit):

Yes, it is silly that Git made the decision to use "reset" to describe SVN's 
"revert", "checkout" to describe "update -r", and use "revert" to describe 
"backout" of a prior changeset (as Mercurial users would describe it). That 
being said,

1. It is really confusing and disruptive to me as a new user that in one 
context "Revert..." means to revert all working copy changes, and in another 
context "Revert" means to backout a changeset. I would strongly prefer if you 
would pick one of these two meanings and apply it consistently throughout the 
whole GUI (i.e. "revert" is as in SVN, or as in Git)
2. Suppose I hadn't had any experience with SVN or any other version control 
system. Now, to understand the concepts behind TortoiseGit, I have to 
understand the basics of Git (for most commands) AND the basics of SVN (to 
understand commands such as checkout and branch that were "borrowed" from 
TortoiseSVN).I also have to constantly ask myself when choosing a command "is 
this an SVN-style command, or a Git-style command"
3. It's unlikely that TortoiseGit will ever completely encapsulate 100% of 
Git's functionality, and even if it does, some users will still prefer to use 
the command line. By defining the GUI commands as you have, you've just made it 
a lot more difficult for users of TortoiseGit to learn command line Git (or 
vice versa)

Now that I'm (mostly) finished my rant, I want to emphasize that one of the 
reasons that I'm so frustrated with this decision is that I think the program 
as a whole is really good Git GUI, and I really WANT to roll it out as the 
"official" Git GUI in my group of 30 developers. But I also know that I have a 
very limited amount of time to convey the essentials of proper use of Git to 
new users (many of which don't like new things, especially ones that are hard 
to use), and I really don't want to waste any of it explaining this kind of 
inconsistency to them.

I hope that you'll have the patience to read through my comment and understand 
where I'm coming from, and hopefully you'll re-open the design choice that 
you've made to mix SVN commands and Git commands in TortoiseGit.

Original comment by brian.bu...@gmail.com on 24 May 2011 at 1:33

[GoogleCodeExporter]

Can you provide suggestion to avoid confuse both old SVN user and new git user?

Original comment by lzn...@gmail.com on 24 May 2011 at 10:07

[GoogleCodeExporter]

My vote: Rename the "Revert..." menu option (explorer context menu) to 
"Reset..." or "Reset/Revert..."

This compiles with GIT and retains the current (and sensible) revert options 
from the show log context menus.  I prefer just "Reset..." myself, though the 
longer version matches with the other dual Svn/Git term items such as 
Switch/Checkout.

Rationale:
Revert is technically correct in both contexts.  Revert from the Log window 
allows one to undo changes.  Revert on the current checkout allows one to undo 
changes.  The difference is that one is undoing changes that have been 
committed/pushed.  The other is undoing changes to a local copy.  "Undo 
changes" is what both actions have in common.  The difference is your 
perception of whether or it's undoing remote changes or local changes.

Subversion itself doesn't really have a "revert this revision" feature -- 
instead relying on reverse-merging changes from the undesirable revision.  
TortoiseSVN and Git *both* did everyone a favor by calling this 'revert' and 
then hiding the annoying paperwork.  Since Subversion also had an existing 
'Revert...' command (equiv to git reset), all TortoiseSVN users have been 
entirely used to this dual-purpose meaning of 'revert.'  Of course, most of us 
didn't see it as dual purpose or confusing -- it made sense (more or less) in 
the way described above.  Revert from the explorer window undoes current 
changes, revert from the log window undoes earlier/committed changes.  It's 
really not that complicated.

... except if you're a longtime Git user --or-- simply reading Git manuals, and 
thusly can't find this frequently-cited "Reset" command in TGit.  Then it gets 
confusing.

Original comment by Jake.Stine on 24 May 2011 at 5:40

[GoogleCodeExporter]

Actually after reading it, my rationale isn't a rationale at all, except to 
prove that the dual meaning has always existed in TSvn.  And after thinking 
about it a few more mins I change my preference to "Reset/Revert..."

(and I reiterate that I don't see any reason to alter the revert commands for 
non-local changes -- the only one that's in doubt here is the "Revert..." 
command available for local changes only, which should be satisfactory for 
everyone if it reads "Reset/Revert...").

Original comment by Jake.Stine on 24 May 2011 at 5:52

[GoogleCodeExporter]

I agree with Jake that changing the command label from revert to Reset/Revert 
would definitely improve things for me. 

Original comment by brian.bu...@gmail.com on 24 May 2011 at 6:02

[GoogleCodeExporter]

\+1 from me

Original comment by leeon...@gmail.com on 24 May 2011 at 6:19

[GoogleCodeExporter]

Let me disagree here.

IMHO TortoiseGit should stick to the git name, meaning and behavior for every 
command. Do not forget its aim is to be a GUI over Git.

If I were an extraterrestrial who didn't know anything about version control 
systems and I came here and learned git as my first VCS, finding a mix of svn 
and git commands and meanings would strongly confuse me. 

Which is exactly what is happening to the 60 people working on a project I 
migrated from ClearCase to git 7 weeks ago: they did not know Subversion at 
all, and they do not want to know Subversion; they only know ClearCase and git, 
and finding this svn "interferences" in the GUI is making their life confusing.

Please, stick to git verbs and behavior for everything. Forget about what 
TortoiseSVN did. TortoiseGit should be "a GUI for git", not "a GUI for git for 
former svn users".

Original comment by elpa...@hotmail.com on 24 May 2011 at 7:07

[GoogleCodeExporter]

I think that either approach would be a vast improvement on the current 
approach. I think that the TortoiseGit team needs to decide whether it wants to 
have "The best Git GUI for former SVN users, and an OK Git GUI for everyone 
else", or "The best Git GUI, period". I won't fault them for choosing the first 
option (although it would be pretty ironic, given Linus Torvalds opinion of 
SVN), but it will also make me more likely to use something like GitExtensions. 
My 2 cents...

Original comment by brian.bu...@gmail.com on 24 May 2011 at 7:28

[GoogleCodeExporter]

Actually, TGit's "revert" from explorer context menu do "git check out -- 
file", not reset. 

Personally, I think there are too much functions in git "reset" and "checkout" 
command. 

TGit target is that make user happen, easy to use and hide some git complex. 

Come back this problem:
Option 1: Reset/Revert
option 2: Undo local change...
Option 3: Revert local change...
.....

How about "Undo local change" 

Original comment by lzn...@gmail.com on 25 May 2011 at 1:57

[GoogleCodeExporter]

+1 for "undo local change" or "undo non committed change", avoids the confusion 
and uses none of the keywords

Original comment by joakim.p...@gmail.com on 28 May 2011 at 12:59

[GoogleCodeExporter]

For now, consistency would be the safest way.  We have "Switch/Checkout..." 
already, so "Reset/Revert..." would be consistent with that, sufficiently 
decreases possible command line confusion, and doesn't lose it's human/natural 
meaning.

I've to agree with Frank's and Jake's follow-ups - for casual users, the git 
command line is a bloody hell.  Only technically versed git power users are 
able to make sense of the badly named and overloaded commands and arguments.  
Personally I'd blame that extremely poor naming as #1 reason for the slow 
adoption of git.

Mainly because of that, the goal of tools like TortoiseGit needs to be to 
provide a user interface for git that primarily focuses on usability and 
accessibility.  Throwing inane terminology at one's face is counter-productive 
in terms of user experience.  git is merely the tool that performs the grunt 
work under the hood.  It runs on the command line, which is a completely 
different context.  Regardless of what you do with anything anywhere in the 
world, it's almost always utterly wrong to apply the same principles from one 
context to a completely different one.

If you'd really want to decrease the UI/shell confusion, then a much more 
proper resolution would be to make the UI show the shell commands it's about to 
invoke.  (Which kinda happens in the Switch/Checkout UI already, but only 
afterwards, not upfront.)

In light of that, whatever makes sense for the average Joe, who may or may not 
be familiar with git's version control system design decisions (doesn't 
matter), should be chosen for the UI.  "Reset/Revert..." seems to resolve this 
issue.

Original comment by dev.unle...@googlemail.com on 29 May 2011 at 6:33

[GoogleCodeExporter]

Um, speaking of consistency, "Switch/Checkout" has human terminology first, git 
terminology last.  Thus, it should equally be "Revert/Reset..."

Original comment by dev.unle...@googlemail.com on 29 May 2011 at 6:39

[GoogleCodeExporter]

Actually, "Revert" is not "git reset", 
"git reset -- file" is used to unstage file from stage area.  
Tgit "revert"  actually "checkout HEAD -- file" to give up local change. 

Original comment by lzn...@gmail.com on 30 May 2011 at 2:22

[GoogleCodeExporter]

It seems that Git GUI uses "Revert Changes" on specific files as the name of 
the menu option instead of checkout also.

It's under "Commit > Revert Changes"

So for Tortoise to use this doesn't bother me so much, but I do think they 
should describe what it's doing better, like "Revert changes for this file..."

Now, I do think that the TortoiseGit Contextual menu item "Revert" is a git 
revert. The reason why I say this is because a ton of files got reverted today 
to a previous commit that I didn't intend to revert (along with a bunch of 
files that got deleted) and I thought that git had done something wrong.  After 
doing some searching I realized I had used that menu option, selected some of 
the items, and clicked okay.

Original comment by nathanwa...@gmail.com on 30 Aug 2011 at 6:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue 1740 has been merged into this issue.

Original comment by sstrickr...@googlemail.com on 24 Jun 2013 at 2:55

[GoogleCodeExporter]

Two members of my team had issues today similar to those detailed in Issue 1740 
and although this issue (634) regarding the revert/reset confusion didn't help 
I don't think resolving 634 will necessarily resolve 1740.

To restate the problem, the user chooses to do a merge then due to the number 
of conflicts decides against doing the merge. The user, being unfamiliar with 
what is actually happening in the background with the git repo, then chooses to 
revert (using the TortoiseGit context menu) the files. They then make some 
non-merge related changes and commit. The user does not realise that they are 
still in the middle of a merge and the repository considers their new commit as 
resolving the conflicts and it is marked as a merge even though no changes from 
the other branch have been used.

Now I understand that this may primarily be a user education issue but I 
believe a couple things can be done to make it easier to avoid this situation:

1) Add a context menu option to abort a merge, equivalent to "git merge 
--abort". This will not prevent the above situation from occurring but at least 
we can direct users to a *correct* way to cancel a merge.

2) Make it more apparent in the commit window that a merge is occurring, 
perhaps by listing both parents. I know that the message is defaulted to a 
merge message but this doesn't appear to be sufficient to indicate to users 
that they are performing a merge, they assume it is a bug or a hold over from 
their "reverted" merge attempt.

Original comment by scottdw0...@gmail.com on 18 Jul 2013 at 1:42

[GoogleCodeExporter]

Is it even possible to abort a merge with TGit?
I don't know how to do that. I'm used to revert to the command line to do it.

I think it would be a (big) improvement to be able to abort the current 
operation (merge, cherry-pick, maybe even rebase) with TGit, and show it is 
going on in the context menu. Maybe a separate issue for this, cause I don't 
think it's related to this, although I think it would be good to show the 
repository state in the revert (or reset/checkout whatever) dialog.

Original comment by jopi...@gmail.com on 18 Jul 2013 at 6:18

[GoogleCodeExporter]

@jopie64 Abort merge implemented as at TortoiseGit 1.8.4.2 preview

Original comment by ch3co...@gmail.com on 10 Aug 2013 at 11:36

[GoogleCodeExporter]

I answered the similar question in mailing list today.
"Revert to this revision" vs "Revert change made by this commit"

Original comment by ch3co...@gmail.com on 21 Feb 2014 at 1:16