Wappler Version : 3.7.4
Operating System : mac
Server Model: node
Database Type:
Hosting Type: custom
Clicking to discard git changes should perform its action
Nothing appears to change
chrome_debug.log 4.zip (2.6 KB)
Screen Recording 2021-02-05 at 1.46.56 PM
Here is the diff for this file (nothing changed):
I wasn’t able to reproduce it. Any changes that I discard performs correctly.
In your case it seems that the file is not modified (or perhaps it is different but you can’t see it, like different newlines). When there is no difference the discard will also not do anything. So the problem seems that it marks the file as modified while it should not.
@mebeingken did you ever get resolution to this issue?
I am seeing the same behaviour in Wappler 4.0.1 albeit with a twist. Modified files are being rolled back, but new files remain untouched.
Delete all uncommitted changes
Ends up as
Interestingly the routes.json has reverted back and removed the entry to test1.ejs, but test1.ejs is still physically present
This seems like a bug to me
@patrick This is still happening in Wappler 4.0.4
Just tried it on a new project, established a GIT baseline
Edited existing index.ejs
Added new file testing.ejs
Produced the following uncommitted files
Select all files and discard all changes
The files that were edited have been removed, but the newly added files have not
I will check it, I believe it is a default behavior of git that it doesn’t delete new files when reverting, it only reverts the files it knows.
I can discard new files from Source Tree from what I remember.
I have been using gitkraken as a work around for this issue and have no problems deleting new files.
We only discard all changes that are being tracked by git. When also deleting uncommitted/untracked files you can’t undo that anymore. It is possible that you delete an important file from Wappler which wasn’t committed and that could break your project.
What we do is like following command with git cli: git reset --hard.
To also delete untracked files git cli has a separate command git clean.
How do SourceTree and GitKraken handle it, do they both commands in a single action and do they warn you about the action can’t be undone?
Not sure about which comman they run. But SourceTree always gives a warning when discarding any change - new file or otherwise, which I think would also be a good addition to Wappler Git in general.
Have accidentally clicked on discard changes insted of show changes in context menu at least once. Thankfully, the changes were not too vast, so was able to redo it from memory.
I am not referring to undoing deletions of uncommitted files
What I am referring to is if I "discard all changes" as shown below
Then I end up with the following
The routes.json file has rolled back as expected
My test.ejs remains behind and is now effectively orphaned as no route exists
Git kraken tells you the following and then removes the uncommitted files new and edited all in 1 swoop
@patrick, do you have any further thoughts on this?
I’m working on it, have some problems with the library that we use, it seems not to always remove the unversioned files while I have set the option that it should do so. So not sure if we will have this working in the upcoming update.
Bump. @patrick
New files still can’t be discarded.
Are you really sure you want this?
So all new files and files not in git control will be actually wiped out…
There is a prompt shown for confirmation. So I don’t think it would be a bad thing to have.
Also, if you think its dangerous to enable on discard all option, enable it on discard of selected file at least.
That has a prompt now as well.
@George I think the way it currently stands is confusing, and incorrect.
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.
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?
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.
From 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. 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?
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.
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.
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.
Bump. @patrick
Really don’t want to use another app for basic Git stuff like discarding files which have no change.
The original issue reported still remains in 4.2.2
To reproduce:
A fix for this would give me one more reason to not use SourceTree.
I will have an other look at it, but not this week. The Git library that we use does not handle this situation correctly and we probably have to do the deleting of the unversioned files separately.
Absolutely agree. This issue should be fixed.
