This will perform git checkout - filename for each selected item. In any case if it is believed that the way it currently behaves in Wappler is correct then I think we are better of to remove the rollback uncommitted files function altogether as in my view partial rollbacks are worse than no rollback. If the items are not staged (in the top pane), you can revert them by right-clicking on one or multiple items and clicking 'revert'. I really love the simplicity of Wappler and the way it allows us to do things in 1 application, but using GIT in Wappler for some things, and having to use a 3rd part GIT application for other functions defeats the purpose in my view. The way I use this often is to start with a clean GIT commit, then play around learning new things in current project and when I have figured it out I will roll back ALL uncommitted changes back to my known commit state. Reload the current repositorys status from the remote server. I guess in essence these new files are not in GIT yet so really don’t see why they shouldn’t be deleted when the user has selected them to be deleted? hg copy z d copying z/a/c to d/z/a/c As with the hg remove command, if you copy a file manually and then want Mercurial to know that you've copied the file.
This behaviour is disorienting and confusing to an end user as without knowing the “how it is supposed to work” causes trust concerns as to what is rolled back and what is not, hence why I started using GitKraken for this function.įrom what I gather it is also different behaviour to the way GIT intended it to be used, at least when I look at how GitKraken does it, but by no means am I a GIT expert. Then through GIT (refer to my screenshot in earlier post) on delete the routes file is rolled back, but the new file remains in place effectively orphaned until a new route is created? Should You Use reset or revert in Git You should really only use reset if the commit being reset only exists locally. In this image, each circle represents a commit. Look at this situation in a nodejs project: lets say a new file is added, the routes file is updated to reflect the new route. git reset -hard HEAD1 This will undo the latest commit, but also any uncommitted changes.
#SOURCETREE DISCARD COMMAND PLUS#
Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications.
I think the way it currently stands is confusing, and incorrect. Prepare to work on top of
0 kommentar(er)
