Community
Participate
Working Groups
I'm using Eclipse 2018-12 M2 on Windows 10. I have a file that has been modified in Git and renamed. In the History tab I can see the list of commits the file has gone through. (The increase in `diff.renameLimit` from Bug 434085 to match native Git helps, thanks.) But when I click on one of the previous commits (before the rename), Eclipse says: > File /project/src/main/java/com/example/FooBar.java is not contained > in the commits: a1b2c3d4... If EGit can figure out the file was renamed, and which file it was renamed from, why can't it open the file (under the previous name) from that commit?
Cannot reproduce. But then I'm not on windows. Try updating to EGit nightly (update site http://download.eclipse.org/egit/updates-nightly ). If the problem persists, please provide more exact steps to reproduce.
I have lots of examples and variations. Let's start with a straightforward one: 1. Clone the `master` branch of https://bitbucket.org/globalmentor/globalmentor-core . 2. Set the `diff.renameLimit` to 999 for this project. (I don't remember if this is required for this case, but you might as well do it so we won't get confused if the history doesn't show up.) 3. Import the project into a standard Enterprise package of Eclipse 2018-12 M2. 4. Open the file `com.globalmentor.java.Strings.java`. 5. Show the file in history. 6. Scroll down to commit `1991aa4f605a7026323068baae9e713df13e4f11` from 2015-12-05 and double-click. The file from that commit opens. 7. Go back and scroll down one more item to commit `3b887d0e36082fa6f44e28bec780d012a6426eb1` from the same day and double-click. Eclipse complains that the file does not exist in that commit, nor in any other earlier commit. Perhaps I am making some erroneous assumption(s): * I assume that if Eclipse shows a commit in the "History" tab for the file, then Eclipse has followed the files history to that commit. (I say that because new files, and files that have been renamed with a `diff.renameLimit` set too low, will not show all available commits.) * I assume that if Eclipse is able to follow a rename to a commit, then it knows that that file used to be called in that commit. * In other words, I assume that for every commit Eclipse shows under the "History" tab for a file, Eclipse should be able to load the file from that commit. I have other more interesting examples. Let me know what you make of this one.
To illustrate some even stranger behavior: open the same file `Strings.java` from the previous comment. Turn on "Show Revision Information". Go to the first line of `trimFirstChar()` (currently line 501), and hover over the commit information. It will show commit `84d0762d8a0723deabb4a2552335cb29c16d622a` in the flyover, with a link to "show in history". Click that link and it will indeed take you to commit `84d0762d8a0723deabb4a2552335cb29c16d622a` in the history tab, Bug: After the above steps, double-clicking on commit `84d0762d8a0723deabb4a2552335cb29c16d622a` in the history tab won't do anything at all! (You can get around this bug by right-clicking on `84d0762d8a0723deabb4a2552335cb29c16d622a`, selecting "Open in Commit Viewer", then closing that window; when you come back to the history tab, you can now double-click on commit `84d0762d8a0723deabb4a2552335cb29c16d622a`.) Bug: Now double-click on `84d0762d8a0723deabb4a2552335cb29c16d622a` (once you've worked around the other bug). It says that the file is not contained in this commit. But the revision information in the margin just told you that this is the commit that the line in the file was last changed in, so how could that be?
(In reply to Garret Wilson from comment #2) > I have lots of examples and variations. Let's start with a straightforward > one: > > 1. Clone the `master` branch of > https://bitbucket.org/globalmentor/globalmentor-core . > 2. Set the `diff.renameLimit` to 999 for this project. (I don't remember if > this is required for this case, but you might as well do it so we won't get > confused if the history doesn't show up.) > 3. Import the project into a standard Enterprise package of Eclipse 2018-12 > M2. > 4. Open the file `com.globalmentor.java.Strings.java`. > 5. Show the file in history. > 6. Scroll down to commit `1991aa4f605a7026323068baae9e713df13e4f11` from > 2015-12-05 and double-click. The file from that commit opens. > 7. Go back and scroll down one more item to commit > `3b887d0e36082fa6f44e28bec780d012a6426eb1` from the same day and > double-click. Eclipse complains that the file does not exist in that commit, > nor in any other earlier commit. > > Perhaps I am making some erroneous assumption(s): > > * I assume that if Eclipse shows a commit in the "History" tab for the file, > then Eclipse has followed the files history to that commit. (I say that > because new files, and files that have been renamed with a > `diff.renameLimit` set too low, will not show all available commits.) > * I assume that if Eclipse is able to follow a rename to a commit, then it > knows that that file used to be called in that commit. > * In other words, I assume that for every commit Eclipse shows under the > "History" tab for a file, Eclipse should be able to load the file from that > commit. > > I have other more interesting examples. Let me know what you make of this > one. I cannot reproduce following the above steps. ~/Git/globalmentor-core $ git log --follow -- src/main/java/com/globalmentor/java/Strings.java commit 4963f7f8bfeef550e3f5b6413372531a8d899e5e Author: Garret Wilson <xxxx> Date: Tue Feb 14 15:04:55 2017 -0200 JAVA-28: Switched to static factory methods for creating Characters instances. commit de1cd93bbf541a10f9f2840e120f9b8f33033597 Author: Magno Nascimento <xxxx> Date: Mon Jun 20 22:52:11 2016 -0300 JAVA-1: fixed javadoc warnings and errors commit 1991aa4f605a7026323068baae9e713df13e4f11 Author: Garret Wilson <xxxx> Date: Sat Dec 5 01:24:28 2015 -0800 Redefined the root of the repository after conversion from Subversion. commit 69826caae91fe7887e6648f29a6dc3b9d0666558 Author: Garret Wilson <xxxx> Date: Sun Aug 31 22:30:10 2014 +0000 Switched to using predefined charset provided by the JDK. ... Same result in Egit. Where's your commit 3b887d0e3? It doesn't show up anywhere if the history is filtered by file. 3b887d0e3 is the direct parent of 1991aa4f, but indeed it did not touch file com.globalmentor.java.Strings.java. If you expect the history to show the history of the currently opened file, set "Link with Selection" ( The button in the view toolbar with two horizontal arrows), and choose "Show all changes of selected resource and its children" (the button with two arrows pointing right, and a file icon).
(In reply to Garret Wilson from comment #3) > To illustrate some even stranger behavior: open the same file `Strings.java` > from the previous comment. Turn on "Show Revision Information". Go to the > first line of `trimFirstChar()` (currently line 501), and hover over the > commit information. It will show commit > `84d0762d8a0723deabb4a2552335cb29c16d622a` in the flyover, with a link to > "show in history". Click that link and it will indeed take you to commit > `84d0762d8a0723deabb4a2552335cb29c16d622a` in the history tab, > > Bug: After the above steps, double-clicking on commit > `84d0762d8a0723deabb4a2552335cb29c16d622a` in the history tab won't do > anything at all! (You can get around this bug by right-clicking on > `84d0762d8a0723deabb4a2552335cb29c16d622a`, selecting "Open in Commit > Viewer", then closing that window; when you come back to the history tab, > you can now double-click on commit > `84d0762d8a0723deabb4a2552335cb29c16d622a`.) Can reproduce this one. I'll have to investigate why and what is supposed to happen. > Bug: Now double-click on `84d0762d8a0723deabb4a2552335cb29c16d622a` (once > you've worked around the other bug). It says that the file is not contained > in this commit. But the revision information in the margin just told you > that this is the commit that the line in the file was last changed in, so > how could that be? Cannot reproduce this one; the version of Strings.java from commit 84d0762d opens fine for me.
> Same result in Egit. Where's your commit 3b887d0e3? It doesn't show up > anywhere if the history is filtered by file. So if I'm trying to use this thing correctly, I'll be happy to find out my problem. I'm simply asking Eclipse to "Show in History" for a file. If Eclipse shows a commit, I assume that the file exists in that commit. Is that a faulty assumption? (I believe it is a reasonable assumption.) > 3b887d0e3 is the direct parent of 1991aa4f, but indeed it did not touch > file com.globalmentor.java.Strings.java. I suppose there are two ways of looking at a commit. The way you're looking at it, you're talking about the _physical storage_ of what was changed (the diff/delta). But another way of looking at it (the way Git actually sells itself) is as a series of logical snapshots, identified by checksum values. In this view, if I check out snapshot 3b887d0e3, I would get a copy of Strings.java, would I not? Perhaps the act of committing did not make changes to Strings.java, but logically it exists in the 3b887d0e3 snapshot doesn't it? (I'm not trying to be argumentative; I'm just pointing out the way a user might look at it.) > If you expect the history to show the history of the currently opened file, > set "Link with Selection" ( The button in the view toolbar with two > horizontal arrows), and choose "Show all changes of selected resource and > its children" (the button with two arrows pointing right, and a file icon). So clicking on the two-arrows-plus-resource icon reduces the number of commits shown, and clicking on any of them gives me a diff. So maybe I was misunderstanding how the tool worked, and assumed that the two-arrows-plus-resource was the thing selected by default (or I didn't realize there were options). I assumed that asking for a history of the file would show me… a history of the file. :) So maybe it's cool to have these other options. I wouldn't say it's all obvious. (Then again, Git itself isn't obvious until one has been using it quite a while.) > Cannot reproduce this one; the version of Strings.java from commit > 84d0762d opens fine for me. It seems to open for me, too. So maybe I did something wrong when I discovered the other bug I found in Comment 5. So to summarize the state of things: * I now understand better how the tool is supposed to work. * There is an option (two-arrows-plus-resource icon) that will only show the commits in which the file was changed, which seems to be what I want. * I may have made a mistake commit 84d0762d; in any case I cannot reproduce the problem either. * There remains a bug in Comment 5 related to opening a commit after viewing it from "Show Revision Information" which you will investigate. I appreciate the help, tips, and enlightenment you've given on this issue.
> So if I'm trying to use this thing correctly … I meant to say "incorrectly".
(In reply to Thomas Wolf from comment #5) > (In reply to Garret Wilson from comment #3) > > To illustrate some even stranger behavior: open the same file `Strings.java` > > from the previous comment. Turn on "Show Revision Information". Go to the > > first line of `trimFirstChar()` (currently line 501), and hover over the > > commit information. It will show commit > > `84d0762d8a0723deabb4a2552335cb29c16d622a` in the flyover, with a link to > > "show in history". Click that link and it will indeed take you to commit > > `84d0762d8a0723deabb4a2552335cb29c16d622a` in the history tab, > > > > Bug: After the above steps, double-clicking on commit > > `84d0762d8a0723deabb4a2552335cb29c16d622a` in the history tab won't do > > anything at all! (You can get around this bug by right-clicking on > > `84d0762d8a0723deabb4a2552335cb29c16d622a`, selecting "Open in Commit > > Viewer", then closing that window; when you come back to the history tab, > > you can now double-click on commit > > `84d0762d8a0723deabb4a2552335cb29c16d622a`.) > > Can reproduce this one. I'll have to investigate why and what is supposed to > happen. This is ugly. The problem is the rename of the file. We actually show the history with the renamed file as input (trunk/globalmentor-core/...). The history doesn't show the history of the file we started from (globalmentor-core/...). The top commit is actually the commit that did the rename. The single-file-mode of the history view, where a double-click would open either the compare editor or the normal editor on that file) works only properly if the given file exists in the file system. But of course there is no file "trunk/globalmentor-core/..." in the file systems because of the rename. This can be fixed kind of for the precise use case in the steps above which start with showing the revision info on the HEAD version. We can just show the history for the path of the HEAD version instead of the before-rename path from the older revision. But that may perhaps give strange results in some other cases. Moreover, if we've opened an older version from the history ("Show revision info" in the context menu in the file diff viewer bottom right in the history page), then we don't have that HEAD path anymore. Following the steps from there on again leads to a history for a renamed file, and again double-clicking won't do anything. Another approach is to lift the assumption that in single-file-mode the file has to exist in the file system. But that breaks a couple of other history commands. Since the path is not in the working tree, we'll get "Compare with HEAD" instead of "Compare with Workspace". But the path isn't in HEAD either, and there's no "reverse rename" information to figure out the correct path. Some other commands also don't work then. I'm not sure this can be fixed completely with reasonable effort.
Now I'm running into another odd problem. Please tell me if it's the same thing or if I need to open another bug ticket. I'm using the recently released Eclipse (Enterprise) 2019-09 on Windows 10. I'm looking at the history view of https://garretwilson@bitbucket.org/globalmentor/guise.git , specifically the file `mummy/src/main/java/io/guise/mummy/deploy/aws/S3.java`. In the history view I have the scope to only show history for the resource. The second commit listed is `9cbdd126df05fe7dd85770814bd6e54efe9bddf8`. The commit shows that `S3.java` was changed in that commit. So I double-click on that entry in the history and it says: > File not Found: File mummy/src/main/java/io/guise/mummy/deploy/aws/S3.java is not contained > in the commits: 9cbdd126df05fe7dd85770814bd6e54efe9bddf8 Surely this shouldn't be that difficult to understand. What am I doing wrong?
The last issue is very odd. It's causing problems even with more recent commits. It seems to be getting confused by renames that happened _days earlier in the history, in previous commits_.
(In reply to Garret Wilson from comment #9) > Now I'm running into another odd problem. Please tell me if it's the same > thing or if I need to open another bug ticket. > > I'm using the recently released Eclipse (Enterprise) 2019-09 on Windows 10. > I'm looking at the history view of > https://garretwilson@bitbucket.org/globalmentor/guise.git , specifically the > file `mummy/src/main/java/io/guise/mummy/deploy/aws/S3.java`. > > In the history view I have the scope to only show history for the resource. > The second commit listed is `9cbdd126df05fe7dd85770814bd6e54efe9bddf8`. The > commit shows that `S3.java` was changed in that commit. So I double-click on > that entry in the history and it says: > > > File not Found: File mummy/src/main/java/io/guise/mummy/deploy/aws/S3.java is not contained > > in the commits: 9cbdd126df05fe7dd85770814bd6e54efe9bddf8 > > Surely this shouldn't be that difficult to understand. What am I doing wrong? Since other issue was lost in the comments, but it's still happening, I opened a separate ticket for it: Bug 564499.
