How do I revert a pull request?

[monkeypunch]

How do I revert to before I did a pull?

Here's the story,

1. I made changes to my local files

2. I see new changes and click the Pull button

3. It says I need to commit my changes first

4. Write ommit message and click Commit

5. Click Pull button

6. A dialog appears that says I have conflicts

7. Find file that has conflicts and open merge tools. I think it showed 4 unstaged files?

8. Right click and select Merge. File merge opens (it sucks). I don't know how to merge. There's no done button, no save button just actions. Switch back to SourceTree nothing's changed. I finally find Save from the File menu. Click that a few times and then close the progra. Not sure if anything is saved.

I don't see any changes but I see a new .BACKUP file in unstaged.

9. Now I see 5 unstaged files the original conflicted file is not in the staged file list.

10. I don't see my original file in the stage or unstaged but I could be remembering incorrectly. I should video this the next time. I give up and go into original file and make changes manually.

11. Now I still have 5 unstaged files.

My question is, can I revert back to before step 5? Before I clicked on pull?

A couple of unpopular ideas. When errors happen explain it as if to a 5 yr old what to do. Add an undo button. Changed the wording from pull to "download", push to "upload", commit to "save" and the tool tip says "save changes before downloading or uploading", remove to "delete" and reset to "undo" (if that's what reset actually does).

I'm sorry for my ranting but git breaks common user interface nomenclature or conventions. We shouldn't be following it's poor choice of words because it's popular. I'm done ranting. I'm sure my gravestone will mention my ranting.

[Seth · Accepted solution]

Yes, you can revert. Right click the commit before the pull, and choose "Reset...". You want to do a HARD reset for the change to effect your working copy.

Also, of course Git breaks "user interface" nomenclature and conventions. It was designed as a command line tool, and follow *nix conventions for those. Tools like SourceTree wrap that command line tool in a UI, but it is important for nomenclature to match the tool's rather than broad "standard" conventions specified by Apple for software that is much simpler.

No offense, but versioning systems aren't designed to be used by five year olds. If you don't know how to merge, versioning isn't for you.

[monkeypunch]

Thanks. I'll give it a try. I've used svn, cvs for years and they had their problems but I don't remember being as perplexed by it as git is. Maybe I've been spoiled. BTW I don't agree that git should remain as hard to use as it is and not be improved.

[monkeypunch]

Thanks. I'll give it a try. I've used svn, cvs for years and they had their problems but I don't remember being as perplexed by it as git is. Maybe I've been spoiled. BTW I don't agree that git should remain as hard to use as it is and not be improved IMHO.

[Seth]

Your opinion is perfectly valid. My point is just that SourceTree can not and should not take the liberty of changing terminology used by the core software (the Git command line tool). Unfortunately, I doubt you'd convince the creators of Git to change any terminology, since it is designed by and for Linux developers.

You may find this quote from wikipedia interesting, as it is one of the design guidelines for Git: "take Concurrent Versions System (CVS) as an example of what not to do; if in doubt, make the exact opposite decision".