• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Git
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      1. Start interactive rebase. Have some problems with finishing it (there are plenty, still don't know how to finish it properly).
      2. Start working on some other stuff (totally forgot about rebase on the next working day?). Switch between branches with no problem.
      3. Press commit your new changes.
      4. Source tree says that rebase is in progress, should we continue? Press [of course] no.
      5. All you changes are reset, even staged. Have a nice day!

            [SRCTREE-7994] Aborting interactive rebase resets all changed files

            7d8f8411c46a,

            Thanks for these suggestions. I'll convert this issue to "Suggestion" and we will take a look on this.

            Raman Sidarakin (Inactive) added a comment - 7d8f8411c46a , Thanks for these suggestions. I'll convert this issue to "Suggestion" and we will take a look on this.

            alexander.danilov added a comment - - edited

            Hi Raman, thanks for explaining, but I totally understood what happened after it already happened.

            But there definitely should not be situation when all your changes are reset such easily just by pressing highlighted button of not very dangerous alert.

            What I suggest:

            1) Stash changes automatically, sometimes source tree does that in dangerous situations. May be even add checkmark to the alert that is enabled by default: "Stash current changes"

            2) Make alert more dangerous, and/or, if there are some changes - show another one after pressing Abort - that "All your changes will be reset. Are you sure?"

            3) Change source tree background color to yellow or red or something like that, make the UI of the app somehow to show that git is not in normal state, but in rebase state, which is not a joke, and you should always keep it in mind, even if you started it on friday and continued working on monday or after you vacation etc etc. Currently I don't notice any changes even if they exist.

            Anyway, there should not be ever in universe such a situation that when you press blue highlighted button of popped up alert, which looks like 'Cancel' to me, all your work for several days is totally removed without any way to restore it.

            alexander.danilov added a comment - - edited Hi Raman, thanks for explaining, but I totally understood what happened after it already happened. But there definitely should not be situation when all your changes are reset such easily just by pressing highlighted button of not very dangerous alert. What I suggest: 1) Stash changes automatically, sometimes source tree does that in dangerous situations. May be even add checkmark to the alert that is enabled by default: "Stash current changes" 2) Make alert more dangerous, and/or, if there are some changes - show another one after pressing Abort - that "All your changes will be reset. Are you sure?" 3) Change source tree background color to yellow or red or something like that, make the UI of the app somehow to show that git is not in normal state, but in rebase state, which is not a joke, and you should always keep it in mind, even if you started it on friday and continued working on monday or after you vacation etc etc. Currently I don't notice any changes even if they exist. Anyway, there should not be ever in universe such a situation that when you press blue highlighted button of popped up alert, which looks like 'Cancel' to me, all your work for several days is totally removed without any way to restore it.

            Hi, 7d8f8411c46a 

            Thanks for contacting us.

            At first I wanted to say, that I am very sorry that you are experienced the resetting of your working copy.

            The most important thing is contained inside your first step. You've started interactive rebase, but started working on other stuff without finishing or aborting your interactive rebase. Let me provide more details.

            The thing is, when you've started interactive rebase - Sourcetree enters kind of "interactive rebase edit" mode, which allows you to resolve conflicts, edit files that contained in rebasing commit, e.t.c. So, you started working on other stuff when interactive rebase was in progress (not finished or not aborted). It means Sourcetree assumes, that all changes made by you during working on other feature are part of "rebase", which is still not finished or aborted. When you tried to commit  - then Sourcetree notified you that interactive rebase still in progress using this dialog: https://drive.google.com/file/d/1C_3cJfvK1BfZ7pLRzKfA5L3gd4n62ZlI/view?usp=share_link 

            First option "Continue Rebase" in this dialog is continues rebase, other words you are telling Sourcetree, that all changes are made as a part of this rebase and we could finish it.
            Second option "Abort Rebase" is aborting rebase, that currently in progress, which involves resetting all changes you are made while interactive rebase was in progress. It resetting changes because you are aborted rebase and it means you do not want rebase any changes from other commit. Other words, Sourcetree restores your working copy to the state, that was before starting interactive rebase. Most probably this is actually your situation, which you are experienced. In case you wanted to preserve your working copy changes, you had to select the third option in this dialog: "Cancel".

            In this particular case "Cancel" will cancel your action (for you it was commit action) and it will let you to save your changes somehow (stash, patch, e.t.c) and only then abort rebase using Sourcetree context menu: Actions -> Abort Rebase.

            So, most probably, it consequence of two circumstances:

            1st is you didn't notice that interactive rebase is in progress and started working on other task (before working in other stuff you had to abort or finish rebase).

            2nd you are selected "Abort Rebase", when tried to commit your changed, which caused aborting rebase and resetting your working copy to the state it was before starting interactive rebase (you had to click "Cancel" to have a change to save your changes before aborting rebase). 

            Please, always use Actions -> Abort Rebase when you do not want to finish rebase and reset all changes that were done during rebase. And please, use Actions -> Continue Rebase when you are ready to continue and finish rebase. 

            Please, let me know if my understanding of your issue is correct, or if you have some additional questions or comments regarding this.

             

            Raman Sidarakin (Inactive) added a comment - Hi, 7d8f8411c46a   Thanks for contacting us. At first I wanted to say, that I am very sorry that you are experienced the resetting of your working copy. The most important thing is contained inside your first step. You've started interactive rebase, but started working on other stuff without finishing or aborting your interactive rebase. Let me provide more details. The thing is, when you've started interactive rebase - Sourcetree enters kind of "interactive rebase edit" mode, which allows you to resolve conflicts, edit files that contained in rebasing commit, e.t.c. So, you started working on other stuff when interactive rebase was in progress (not finished or not aborted). It means Sourcetree assumes, that all changes made by you during working on other feature are part of "rebase", which is still not finished or aborted. When you tried to commit  - then Sourcetree notified you that interactive rebase still in progress using this dialog: https://drive.google.com/file/d/1C_3cJfvK1BfZ7pLRzKfA5L3gd4n62ZlI/view?usp=share_link   First option "Continue Rebase" in this dialog is continues rebase, other words you are telling Sourcetree, that all changes are made as a part of this rebase and we could finish it. Second option "Abort Rebase" is aborting rebase, that currently in progress, which involves resetting all changes you are made while interactive rebase was in progress. It resetting changes because you are aborted rebase and it means you do not want rebase any changes from other commit. Other words, Sourcetree restores your working copy to the state, that was before starting interactive rebase. Most probably this is actually your situation, which you are experienced. In case you wanted to preserve your working copy changes, you had to select the third option in this dialog: "Cancel". In this particular case "Cancel" will cancel your action (for you it was commit action) and it will let you to save your changes somehow (stash, patch, e.t.c) and only then abort rebase using Sourcetree context menu: Actions -> Abort Rebase. So, most probably, it consequence of two circumstances: 1st is you didn't notice that interactive rebase is in progress and started working on other task (before working in other stuff you had to abort or finish rebase). 2nd you are selected "Abort Rebase", when tried to commit your changed, which caused aborting rebase and resetting your working copy to the state it was before starting interactive rebase (you had to click "Cancel" to have a change to save your changes before aborting rebase).  Please, always use Actions -> Abort Rebase when you do not want to finish rebase and reset all changes that were done during rebase. And please, use Actions -> Continue Rebase when you are ready to continue and finish rebase.  Please, let me know if my understanding of your issue is correct, or if you have some additional questions or comments regarding this.  

              Unassigned Unassigned
              7d8f8411c46a alexander.danilov
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: