Interactive rebase quits in progress on timeout, does rebase without applying changes

[vadsiraly]

We are trying to rebase a ~100 commit branch to master, during interactive rebase, after a few minutes the dialog just closes by itself, and the rebase is done (there were no conflicts, we rebased multiple times in the past, using the traditional rebase featue), and none of the changes we set in the interactive rebase window are applied.

We are using the Windows client version 1.29.1.0.

[DanPristupov]

I hope you made a backup commit.

1. How long did the rebase take? I suspect, it might be a timeout.
2. Can you reproduce the problem?
3. Did you make any changes to those 100 commits? How many?
4. Could you please check the log: %localappdata%\fork\logs\fork.log. While it's not really helpful with IR, it can contain the error at least.

[vadsiraly]

Yeah, no data was lost or anything. But it would be nice to use this feature as it's way cleaner than GitExtensions' for one.

1. It wasn't even 5 minutes, maybe like 2 minutes ?
2. Yes, it happened to everyone in the team who tried to use the interactive rebase feature.
3. We made approximately 5-10 edits to the commits.
4. Sure:

I 2019-03-04 07:44:33.165 Start ipc server Fork_17884_PipeRI D 2019-03-04 07:44:33.165 Waiting for next cross-process event '831' D 2019-03-04 07:44:33.870 Received cross-process event '831' D 2019-03-04 07:44:39.025 Waiting for next cross-process event '244' W 2019-03-04 07:44:39.103 Git request caused error '-c rebase.instructionFormat=#!%H -c rebase.abbreviateCommands=true -c sequence.editor="C:/Users/user/AppData/Local/Fork/app-1.29.1/Fork.RI.exe" -c core.editor="C:/Users/user/AppData/Local/Fork/app-1.29.1/Fork.RI.exe" rebase -i --autosquash 51ffb8ffd93eed172cf5665832e8fda9da97aedf': error: nothing to do

I 2019-03-04 07:44:39.291 RefreshRepositoryData D 2019-03-04 07:44:39.307 SEC RefreshRepositoryDataGitCommand -115 I 2019-03-04 07:44:39.291 Stop ipc server Fork_17884_Pipe_RI D 2019-03-04 07:44:39.411 SEC Repository data are equal. No Changes I 2019-03-04 07:44:39.411 RefreshRepositoryStatus I 2019-03-04 07:44:39.604 Refresh 'SEC' status. Updated 0 files I 2019-03-04 07:44:39.604 RefreshAheadBehindInfo I 2019-03-04 07:44:55.458 RefreshRepositoryData D 2019-03-04 07:44:55.458 SEC RefreshRepositoryDataGitCommand -115 D 2019-03-04 07:44:55.581 Detected changed HEAD I 2019-03-04 07:44:55.685 Refresh 'SEC' data. Updated. I 2019-03-04 07:44:55.706 RefreshRepositoryStatus I 2019-03-04 07:44:56.023 Refresh 'SEC' status. Updated 0 files I 2019-03-04 07:44:56.023 RefreshAheadBehindInfo W 2019-03-04 07:45:03.948 Git request caused error 'branch -d branchname': error: The branch 'branchname' is not fully merged. If you are sure you want to delete it, run 'git branch -D branchname'.

The last warning line is me deleting the local branch, to re-checkout the remote, since while the dialog closed abruptly, the rebase did happen, without my settings applied.

[DanPristupov]

error: nothing to do

That is important. Thank you.

OK, I'm going to try to reproduce that.

Could you contact me by email, so I could help you faster? winsupport@forkapp.io

[vadsiraly]

Don't worry, this issue is not urgent for us by any means.

[DanPristupov]

Just want to say, that most likely the problem is related to your environment (or may be to a particular commit). I just rebased 500 commits without a problem (it took about 10-20 seconds, btw).

Try to run git gc in terminal, it may significantly improve the performance.

[vadsiraly]

We have rebased multiple times without error. The issue only occurs during interactive rebase, and needs a few minutes of tinkering with commits, when the window closes suddenly, and the deed is done.

I don't think this is related to any commit, since the issue occurred with a completely different branch as well in our team. In that case the interactive commit widows just quit, but the rebase did not happen. (It's more than likely that there were many conflicts during that rebase, unlike in our case.)

[vadsiraly]

Just reproduced the issue. Attaching the full logs. It took almost exactly 5 minutes to happen with the interactive rebase dialog open. We restarted the client and deleted the logs to have a full log with only the issue in it:

D 2019-03-04 11:19:57.999 Loading settings. I 2019-03-04 11:19:58.045 Start ipc server Fork_48360_Pipe_AskPass D 2019-03-04 11:19:58.045 Waiting for next cross-process event '968' I 2019-03-04 11:19:58.198 Fork 1.29.1.0 at C:\Users\user\AppData\Local\Fork\app-1.29.1\Fork.exe I 2019-03-04 11:19:58.198 Git Location: C:\Users\user\AppData\Local\Fork\gitInstance\2.20.1\bin\git.exe I 2019-03-04 11:19:58.198 Log target: AppData log file I 2019-03-04 11:19:58.370 Last update check: 3/4/2019 6:47:43 AM. Next one: 3/5/2019 6:47:43 AM I 2019-03-04 11:19:58.509 Restoring 3 sessions. I 2019-03-04 11:19:59.266 RefreshRepositoryData D 2019-03-04 11:19:59.266 SEC RefreshRepositoryDataGitCommand All I 2019-03-04 11:19:59.266 Main: 326, Window: 656, WindowLoaded: 309, UiReady: 769, Total: 1735 D 2019-03-04 11:19:59.669 Loading SEC settings. I 2019-03-04 11:19:59.851 Refresh 'SEC' data. Updated. I 2019-03-04 11:19:59.881 RefreshRepositoryStatus I 2019-03-04 11:20:00.358 Refresh 'SEC' status. Updated 0 files I 2019-03-04 11:20:00.421 RefreshAheadBehindInfo I 2019-03-04 11:20:11.499 Start ipc server Fork_48360_Pipe_RI D 2019-03-04 11:20:11.499 Waiting for next cross-process event '156' D 2019-03-04 11:20:12.449 Received cross-process event '156' D 2019-03-04 11:25:12.607 Waiting for next cross-process event '761' I 2019-03-04 11:25:26.362 RefreshRepositoryData I 2019-03-04 11:25:26.362 Stop ipc server Fork_48360_Pipe_RI D 2019-03-04 11:25:26.362 SEC RefreshRepositoryDataGitCommand -115 D 2019-03-04 11:25:26.757 Detected changed HEAD I 2019-03-04 11:25:26.851 Refresh 'SEC' data. Updated. I 2019-03-04 11:25:26.875 RefreshRepositoryStatus I 2019-03-04 11:25:27.573 Refresh 'SEC' status. Updated 0 files I 2019-03-04 11:25:27.611 RefreshAheadBehindInfo

No error in the logs this time, but the "Detected changed HEAD" seems strange, could it trigger some event, that would close the dialog and do the rebase ? Could the refresh data be the culprit ?

EDIT: We could also reproduce the issue by just opening an interactive rebase dialog to any commit and do nothing. After ~5min the dialog will close every time.

[DanPristupov]

:)

[vadsiraly]

When can we expect a fix for this issue?

[DanPristupov]

What timeout would be enough for you? Interactive Rebase process is being run as a separate process and I don't want to leave it alive forever in a case something went wrong.

[vadsiraly]

I'd say around 1-2 hours would be great.

[DanPristupov]

No, I think you need to use command line for such cases.

[vadsiraly]

Sad to hear that. Can't you make it editable from the registry, so it's hidden from most of the users ?

[vadsiraly]

The behavior that after the timeout, it does the rebase without the changes applied is still incorrect, though.

[DanPristupov]

Yes, I agree. Thank you for reminding me about that.

[vadsiraly]

The timeout could also be increased to the level you think is still "safe". You didn't mention where you'd put that limit.

[DanPristupov]

To be honest, 5 minutes is seems to be a good value, but I can increase it to 10 minutes.

However I think, if 10 minutes is not enough, most probably you are doing something wrong.

• run gc
• If you have a huge repo with a lot of binary data, then you should optimize it.
• if you want to rewrite whole history of a repo, then GUI is not an appropriate tool for that, use CLI there (that's what I would do myself in such case).

Update: It works like following (simplifying). IR blocks editing for whole repository and waits for the editor (which is Fork in this way) to create a todo-list for it. If the process hangs, the repository will remain blocked. So, Fork starts IR and lets the user 5 minutes for editing.

Update2: I see now. You don't have a problem with long rebase. You have a problem with long editing. Then please ignore the beginning of this message.

I'm not sure how to solve that quickly. There are many IPC-communications during IR and I don't want to perform such stuff without timeouts. I might need to rework whole IR-flow.

However I can increase the timeout to 10 minutes to make things a bit better :)

[vadsiraly]

I see now. You don't have a problem with long rebase. You have a problem with long editing.

Exactly! We have a branch, many of us are working on it and when we want to merge that back to master, we want to simplify it. That would be our use case.

But we'll see into other options, I know gitextensions provides some kind of text based IR feature, but this one seemed so much cleaner and easier to use. I understand the concern, don't worry about the timeout in this case.

[DanPristupov]

@vadsiraly I can create an option to change/disable the timeout for you.

However, now when I understand the problem better I'd recommend you a different approach.

I never perform too many IR changes as one operation because it's very easy to make a mistake. Especially, if there are conflicts. I always do like following:

1. Make IR to some point in the past (to a commit in the same branch) and improve the commits. Fix-up WIPs, fix typos etc. I make only small and simple modifications. Then enable backup tag and confirm.
2. Now we have a better commit line and a backup tag for a case we did something wrong. If everything is OK, I remove the tag, otherwise reset --hard current branch to old point which is hold by the tag.

Repeat 1-2 until you are ready to merge/rebase to master.

Performing IR this way I can gradually improve the branch, reorder the commits and be sure that I don't break anything. Sometimes I make up to 10 rebase operations until I happy with then result. Then I remove the backup tags.

Feel free to ask if something is not clear.

[cg110]

I think I keep hitting this issue where interactive rebase closes (and as this is the only tool I've found that does rebase decently I've been using it a lot)

I tend to be tidying up changes, and summarizing the commits. Is there a way to not have it throw away all the work I've done. In the latest case I'm rebasing maybe 20 commits fixing up to 2 proper commits (so checking what's in each commit to move/fixup to the right bits), and was part way through adding a decent change description and the dialog just closes throwing everything I've done away. Can we have some kind of warning, or save, or something? Having the dialog just close and loose work isn't nice :(

I'm using fork v1.42.6.0

[vadsiraly]

Yeah, an option to increase the timeout would be welcome. I'd take the risks associated with it.

[DanPristupov]

I increased the timeout to 15 minutes in 1.45.

[vadsiraly]

Did the behavior change when the timeout is hit, or this just means that a bigger chunk of edits will be discarded? :)

[bababash]

This has been happening to me using 1.81.1.0 It took about 5 minutes before the dialog closed and it started the rebase process

🔷 2023-02-09 08:41:15.604 WindowActivated
🔷 2023-02-09 08:41:15.604 Application Window Activated
🔷 2023-02-09 08:41:15.604 RefreshRepositoryData
◽️ 2023-02-09 08:41:15.604 ctcs RefreshRepositoryDataGitCommand DefaultRefresh
◽️ 2023-02-09 08:41:16.044 ctcs Repository data are equal. No Changes
🔷 2023-02-09 08:41:16.044 RefreshRepositoryStatus
🔷 2023-02-09 08:41:16.503 Refresh 'ctcs' status. Updated 0 files
🔷 2023-02-09 08:41:42.659 RefreshRepositoryData
◽️ 2023-02-09 08:41:42.659 ctcs RefreshRepositoryDataGitCommand Head, Submodules, BugtrackerSettings, CustomCommands, LocalBranches, Status
◽️ 2023-02-09 08:41:43.321 - refs/heads/bootstrap-5
◽️ 2023-02-09 08:41:43.321 + refs/heads/bootstrap-5
◽️ 2023-02-09 08:41:43.321 + refs/heads/web-reports
◽️ 2023-02-09 08:41:43.321 - refs/heads/web-reports
◽️ 2023-02-09 08:41:43.321 Detected HEAD change
🔷 2023-02-09 08:41:43.321 Refresh 'ctcs' data. Updated.
🔷 2023-02-09 08:41:43.321 RefreshRepositoryStatus
🔷 2023-02-09 08:41:47.413 Refresh 'ctcs' status. Updated 0 files
🔷 2023-02-09 08:42:57.920 Start IPC server Fork_Pipe22196_RI
◽️ 2023-02-09 08:42:57.920 Fork_Pipe22196_RI: waiting for next event '717'
◽️ 2023-02-09 08:42:58.953 Fork_Pipe22196_RI: received event '717'
🔷 2023-02-09 08:52:32.463 Automatically fetching 'ctcs'
🔷 2023-02-09 08:52:32.678 Automatically fetching 'merge'
◽️ 2023-02-09 08:52:33.207 Fork_Pipe22196_AskPass: received event '824'
◽️ 2023-02-09 08:52:33.207 Fork_Pipe22196_AskPass: waiting for next event '74'
🔷 2023-02-09 08:52:35.104 RefreshRepositoryData
◽️ 2023-02-09 08:52:35.104 ctcs RefreshRepositoryDataGitCommand Revisions, References
◽️ 2023-02-09 08:52:35.529 ctcs Repository data are equal. No Changes
◽️ 2023-02-09 08:57:59.576 Fork_Pipe22196_RI: waiting for next event '636'
⚠️ 2023-02-09 08:58:20.879 Git request failed'-c core.commentChar=^ -c rebase.instructionFormat=#!_%H -c rebase.abbreviateCommands=true -c sequence.editor="C:/Users/bababash/AppData/Local/Fork/app-1.81.1/Fork.RI.exe" -c core.editor="C:/Users/bababash/AppData/Local/Fork/app-1.81.1/Fork.RI.exe" rebase -i --autosquash b9b0abc50b870107e9988640df522938d4e32c9e':

[robertsynoradzki]

This still happens! I've lost all my pending changes several times now!

[sswires]

This is an extremely annoying issue that still affects 1.95.0.0, and when interactive rebase window dismisses itself, it attempts to rebase non-interactively.