Community
Participate
Working Groups
At a closer look the following is a PEBKAC, but I've repeatedly lost data using this recipe: 1. make changes 2. stage changes 3. find that some changes shouldn't be there 4. double click the staged file 5. in the compare editor revert some changes (push from right to left) 6. save 7. find file under unstaged changes again 8. move file back to staged changes 9. close compare editor the saved reverts are nowhere to be found. The closer look reveals: Step 5 & 6 produce changes directly into the git index, not into the workspace. The diff signalled at step 7 means the index is good the workspace is bad. The move in 8 overwrites the good reverts with the bad previous state. I believe this is the only scenario where a user directly writes into the index bypassing the workspace. 2 Problems: * Users like me who are not aware that they are editing the index, get - let's say: - confused ... * It seems, to make this work as desired, a user has to move the desired reverts twice: from head to index and then from index to workspace. If that's a lot of changes than a lot of work as to be done redundantly. Would it make sense to prompt the user when saving at step 6: "You are about to save your changes into the git index. Should the workspace copy be updated, too? [ ] remember this decision. [Yes] [No]"
I don't know whether it is a bug or feature. If a staged file is double-clicked in 'Git Staging View' then the Compare Editor opens the staged version and the HEAD version of a file. If some changes are made within this editor and saved then the staged version was changed only! I think this is completely counterintuitive too. I would expect that the saved changes affect the workspace version and not the index version of a file.
In all the years with git this is a recurring issue for me. In some (very few) situations it is actually cool to edit the index without affecting the workspace (e.g., I have some debug sysout, that accidentally got staged => remove it from index while keeping it in the workspace). Still, in the vast majority of cases the intention is to update both index AND workspace. I still believe the additional prompt proposed in comment 0 would be perfect.
You can edit the left side? I can only edit the right side with EGit 5.6.0. Which file type do you edit, and which compare do you use?
(In reply to Filipus Klutiero from comment #3) > You can edit the left side? I can only edit the right side with EGit 5.6.0. > Which file type do you edit, and which compare do you use? Since left and right sides of compare editors may have changed since I reported this, I should perhaps say "push from HEAD to index" (rather than "from right to left").
