2

I'm someone which often rebases feature-related commits for fixing them up. Lately I've been concerned in whether having the main coding IDE open can affect something going wrong in the rebase process.

For instance, when there's a "pause" within the rebase process because user is to perform some action (e.g. renaming a cetain commit), would clicking on the usual "file changed externally, refresh it?" prompts that some IDEs offer -before completing the rebase- affect the final working directory state upon rebasing in contrast to keeping the editor closed?

This concern usually makes me wonder whether I should close the editor or not before rebasing commits involving certain loads of changes, and I usually go depending on my feeling at the moment. Of course, I'm also concerned because I have feared in the past that some changes had been potentially lost due to this kind of scenario (althought, in that case, I could also have messed something Git wise).

EDIT: I realize now that when being prompted with the dialogs similar to "File changed externally, refresh it?" caused by rebasing (for the case) it shouldn't cause any problem since file already changed as rebasing pleased. Therefore, what I want to know now is:

Q2) What if when being prompted with "File changed externally, refresh it?" you click No, so that file reverts its contents to the old, and then you save that file and continue the rebasing process? (e.g. closing the active interactive summary tab in case of renaming a commit, or performing a git rebase --continue after resolving some conflict, not necessarily in the externally changed file). Would it cause the file to end with different contents after completing the rebase in contrast to not having re-saved the old overridden contents manually?

Adrián
  • 45
  • 1
  • 3
  • 12
  • 3
    What _is_ the "main coding IDE"? – matt Mar 28 '21 at 00:27
  • This really depends on how smart/dumb/stubborn/pigheaded your IDE is and whether it's meant to work *with* Git. It also depends on certain OS features: on Windows, for instance, an IDE could hold mandatory locks on files and prevent Git from working. That would be a bad, stubborn, poorly-integrated-with-Git Integrated Development Environment that you probably would not want to use. But such IDEs do (or did once) exist, and you didn't say which IDE you are using. – torek Mar 28 '21 at 01:46
  • @matt I refer with the "main IDE" to the editor used for the repository files, not to confuse with the rebasing one (they're usually different in my case), since rebasing tab/window would clearly never be affected in practice – Adrián Mar 28 '21 at 02:40
  • 2
    So you refuse to reveal the name of the editor? – matt Mar 28 '21 at 02:42
  • I wanted not to give focus to any specific IDE since there are multiple I could list, or I may use a new one in future. But if it's important, the well-known ones I'd be more interested on are Visual Studio 2019 (Windows) and VSCode under Windows and Linux. – Adrián Mar 28 '21 at 02:51
  • @matt Note I answered generically, since I thought you asked generically as well – Adrián Mar 28 '21 at 02:59

3 Answers3

2

Having your IDE open while doing a git rebase is no problem. You don’t need to close it. Your concern about doing git operations in your IDE while doing a git rebase on the other hand is a valid one. I suggest you to do that afterwards. Most things won’t cause a problem - but why should you force it?

LeonMueller - OneAndOnly
  • 84
  • 4
  • What kind of operations do you mean? Note I wasn't including in my concern the case of resolving conflicts between sections of code, triggered by rebasing (which can happen), since that situation already validates/expects editing and saving (to resolve the conflicts) from Git perspective, so I don't think that could affect anything other than resolving the conflicts wrong – Adrián Mar 27 '21 at 22:56
2

Git is only using the changes you staged when using git add what you (or you IDE , or any program) does to your files won't affect the staged changes (which you can commit).

If your IDE modifies your files while you are solving the conflicts of a rebase you may actually have a wrong version after you git add ... + git rebase --continue => this sounds very unlikely, but if you don't trust your programs this might be the moment they may affect.

Ivan
  • 1,352
  • 2
  • 13
  • 31
2

Is it safe to rebase while main IDE is open?

Yes¹

Because the IDE being open, unless it's saving files none-interactively or something, isn't going to affect/change files on disk.

What IDE operations are fine?

Anything which does not affect the working copy, examples:

  • Clicking yes when prompted with file changed externally, refresh it?
  • Loading/browsing files
  • git log
  • git show
  • git fetch
  • etc.

What IDE operations are a problem?

Anything which unintentionally (in terms of the in-progress git rebase) updates files, or a git write operation, examples:

  • Ignoring that an open file has contents from before the rebase and saving it anyway
  • Clicking yes when prompted with save this file before quitting?
  • git checkout <branch>
  • git checkout -- file
  • git commit
  • git merge
  • git pull
  • etc.

If you want to, for example, use your IDE to resolve a conflict - that's perfectly fine, if the intent is to update a file during a rebase - there's no problem using your IDE to do so :).

¹ - As Torek commented, there are or were IDEs/editors which may be problematic, but that would be exceptionally rare and not the rule today.

AD7six
  • 63,116
  • 12
  • 91
  • 123
  • Thanks for the clear answer, however, I realized something and edited my post with a newer question, which is what I should have asked in first instance and it's very important, or directly the key point here. Could you answer it? Or is it what you already mean by "Clicking yes when prompted with save this file before quitting"? – Adrián Mar 28 '21 at 22:09
  • `you click No, ... and then you save that file` - I already answered this question :). Clicking "no" won't do anything, just keeping the stale version-in-memory inside the IDE the same. If you _then_ save the file, whatever is in the IDE will become part of the changes being rebased. – AD7six Mar 29 '21 at 07:42
  • Given your doubts, I suggest playing out any scenario you're concerned about, bearing in mind that it is almost always possible to undo a git mistake. So e.g. open some files in your IDE make some 'unwanted' edits, `git checkout -b example`, `git rebase -I HEAD^10`, save those edits, complete the rebase and look at the result. `git reflog` is also super handy to see what you've done and for example get back to where you were with `git reset --hard sha-before-i-borked-that-rebase`. – AD7six Mar 29 '21 at 08:01
  • I guess with your answer it's enough, that makes much sense. I just hope I didn't reach that mistake in the past and remind myself to be careful with that. – Adrián Mar 30 '21 at 08:10