Changes in staged files made in the compare view are ignored
laeubi opened this issue · comments
Version
6.9.0.202403050737-r
Operating System
Linux/Unix
Eclipse version
2024-03
Bug description
- stages a file using staging view
- double-click the file and change some text
- save the file
- it is now shown as changed in the staging view
- add it to the index
Actual behavior
The file now shows as saved with the made changes, but closing the compare editor and open the file or compare it again it shows that the file is actually not changed all changes are lost.
Expected behavior
Changes made in the compare editor are reflected in the workingcopy / index / ...
Relevant log output
No response
Other information
No response
Changing a staged file modifies the index. After save, the on-disk copy of course is different from the index (and does not have the changes you just made in the index), hence it appears as having unstaged changes. When you the stage that unstaged file again, you undo the changes you made in the index.
As far as I see this is not a bug and everything is working as it should.
(Perhaps EGit could warn about this if the index timestamp is newer than the file timestamp? Not 100% sure that's possible or a good idea... timestamps in a git repo can be tricky, and may not necessarily be correct.)
It has worked in previous versions of Egit and renders the compare view completely useless as one has always take care if the file is staged or not, e.g. I have the following cases:
- The file is new -> I can edit in the compare window without a problem and then add the file to the index -> works
- The file is modified but not added to the index yet -> I can edit in the compare window without a problem and then add the file to the index -> works
- The file is already at the index, I can edit in the compare window and even save the file but as soon as I add the file to the index may changes are gone
In contrast, if I edit the file not with compare editor but using a regular editor, then edit the file and add it to the index after save my changes are not lost even though the file is staged.
So even if we assume that from git perspective everything "as it should" from a user perspective it is a bug:
- either the compare editor should behave as if I edit it with a "regular" editor or
- the compare editor should simply not allow any modifications (even though from user point of view this feels wrong and cumbersome)
What are you editing? Index or working tree? What file names etc. does the compare editor show at top of the editable areas? How do you open the compare editor? (Clicking on the file name in the "unstaged changes" viewer in the staging view? Or clicking on it in the staged changes" viewer?)
What are you editing? Index or working tree?
See this Video:
Peek.2024-03-22.13-42.mp4
So it show I'm edit the "index", but afterwards it shows my unstaged changes so I would (naively) assume it has made a change to the "workingcopy" and I must add it to the index, but this leads to instantly undo my changes made in the compare view.
I'm not sure when exactly that changed, I noticed it since a while and it is highly confusing because if one is not really really careful one would not notice that easily.
So assuming I really edit the index here, I would after that edit not like to see a "Unstaged changes", if I do edit the workingcopy I would like the changes to be reflected in the open editor as well.
This one is of course easy, but assume I have a large list of files to work on one can mess up thing way to easy and it is completely counter intuitive.
So it is exactly as I described in my first comment.
- You open the compare editor from the staged changes. That gives you a compare editor with the index content (left) and the last committed version (HEAD, right).
- You edit the index. The change is saved into the index; the working tree file is left unchanged.
- Because now the working-tree file differs from the index, it appears in the "unstaged changes" section.
- You stage the unstaged working tree file. This puts the contents of the working-tree file into the index. You just overwrote the changes you had previously made in the index.
No bug there.
No bug there.
So if its not a bug how can I disable the "feature"? As said that makes (edit) comparing files that are already added to the index completely useless, I can't think of a usecase where in such case I want to only edit the index and be left with a dirty workingcopy that will effectively undo what I changed and after commit needs to reset to HEAD...
This is the staging view, and the functionality it provides is tailored to staging, i.e., preparing a commit.
If you want to compare the working tree against HEAD and edit the working tree file, you might just use "Compare With->HEAD revision" on the file in the editor or package explorer instead of clicking the staged entry. The staged entry is not a file, it is the index entry. It just happens to have the same name and path as a file.
Whenever the same file appears as both staged and unstaged, you have to be careful. It means one of three things:
- the file was edited after it had been staged. Just stage again.
- the file was only partially staged (i.e., open the compare editor from the unstaged view, then copy only some of the changes over to the "index" side, then save -- useful if you don't want to include all file changes in a commit).
- the index was edited. (Equally useful. Typical use case: you add new feature, change some dozens lines of code. Then notice a typo in some comment, also fix that. Stage the file. Write the commit message describing the change, start typing "Also fix a typo." Realize that fixing the typo has nothing to do with the feature; you'd prefer to commit it separately. Open the compare editor from the staged view, undo the typo fix. Save the index change; commit. The working tree file still has the typo fix. Stage now and do a second commit for the typo fix.)
Yes comparing in the editor works, but is quite cumbersome, assume there is no editor open one has first "right-click > open Workingtree", then right-click>compare>head.
I now even tried using "Compare with Workingtree" that then gives no diff at all :-\
Don't get me wrong it might make perfectly sense from git point of view, but hard to understand/use by the user ... so maybe I want something like "compare with head" in the editor, and be able to select it as the double click action in staging view ;-)
@laeubi it has worked like this since the beginning of egit. I know because I also made the same observation many years ago. If you never ran into the issue before, it's probably because you always edited in the compare editor from unstaged until now.
@tomaswolf I know that from a technical point of view this functionality is useful to prepare partial commits, but I have the feeling this is probably extremly seldomly used. I'm certain that none of my colleagues even knows that feature, and I myself have used that less than one time per year, for sure. Therefore I can imagine that in a broader user base that's used more accidentally than on purpose. And in that case changing the behavior to (optionally) always open the compare on the working tree version might be useful. I believe that most users just think of "the file" when triggering user operations in the staging view, no matter whether its in staged or unstaged part.
I noticed that when there is a merge conflict EGit ask me for different options what should be used for the compare (+ an option to sue the choice as the default), maybe something similar can be archived here like:
- Compare Index with HEAD (I think that's what currently happens?)
- Compare Workingcopy with Index
- Compare Workingcopy with HEAD (that probably what I actually want?)