-
Notifications
You must be signed in to change notification settings - Fork 10
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interactive rebase quits in progress on timeout, does rebase without applying changes #186
Comments
I hope you made a backup commit.
|
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.
I 2019-03-04 07:44:33.165 Start ipc server Fork_17884_Pipe_RI I 2019-03-04 07:44:39.291 RefreshRepositoryData 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. |
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 |
Don't worry, this issue is not urgent for us by any means. |
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 |
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.) |
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. 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. |
When can we expect a fix for this issue? |
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. |
I'd say around 1-2 hours would be great. |
No, I think you need to use command line for such cases. |
Sad to hear that. Can't you make it editable from the registry, so it's hidden from most of the users ? |
The behavior that after the timeout, it does the rebase without the changes applied is still incorrect, though. |
Yes, I agree. Thank you for reminding me about that. |
The timeout could also be increased to the level you think is still "safe". You didn't mention where you'd put that limit. |
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.
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 :) |
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. |
@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:
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. |
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 |
Yeah, an option to increase the timeout would be welcome. I'd take the risks associated with it. |
I increased the timeout to 15 minutes in 1.45. |
Did the behavior change when the timeout is hit, or this just means that a bigger chunk of edits will be discarded? :) |
This has been happening to me using 1.81.1.0
|
This still happens! I've lost all my pending changes several times now! |
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. |
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.
The text was updated successfully, but these errors were encountered: