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.
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.
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".
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Supported Platforms macOS Windows To make using Sourcetree as simple yet powerful as possible we embed (bundle) dependencies such as Git, Git LFS, and Mercurial. We strive to keep these...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs