Community
Participate
Working Groups
Bug 360536 should not happen. EGit seems to unpack tag names into separate .git/refs/tags/* files rather than leaving them in .git/packed-refs. This causes trouble on Windows with a case-insensitive file system if the repository contains tags that only differ in case (R36x_v20110210 vs r36x_v20110210).
Created attachment 218336 [details] Screenshot This behavior worsened in master (2.1. nightly builds) for conflicting tag names that point to the same SHA1, e.g. tags "Cheetah" and "cheetah" in git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git that are both b2b2f79127ceb81a70f0a7e9c4a14a4c97a6bb69 In 2.0, you would just see both tags in the initial Pull/Fetch dialog, and after that, fetches silently worked. In master, you now always get an invalid error "<tagname> [lock fail]" with tooltip "couldn't lock local tracking ref for update". This not only happens on the first fetch but on all subsequent fetches. The command line keeps talking about a [new tag] on every fetch, but doesn't issue an error: $ git fetch From ssh://git.eclipse.org/gitroot/jdt/eclipse.jdt.core * [new tag] cheetah -> cheetah * [new tag] v_A58 -> v_A58 From ssh://git.eclipse.org/gitroot/jdt/eclipse.jdt.core * [new tag] cheetah -> cheetah * [new tag] v_A58 -> v_A58 The workaround on Windows for dealing with such remote repos is to do this on the command line: $ git pack-refs
The solution would be to delete one of these duplicate tags on the remote repository. Otherwise this will just make trouble and if they point to the same commit, it was a mistake in the first place. (It would also make trouble e.g. in Subversion, where tags are also directories.)
(In reply to comment #2) > The solution would be to delete one of these duplicate tags on the remote > repository. Otherwise this will just make trouble and if they point to the > same > commit, it was a mistake in the first place. (It would also make trouble e.g. > in Subversion, where tags are also directories.) Nope, this is not a solution but a wrong workaround. This works fine on case-sensitive file systems and also on Windows if the refs are packed.
(In reply to comment #3) > (In reply to comment #2) > > The solution would be to delete one of these duplicate tags on the remote > > repository. Otherwise this will just make trouble and if they point to the > > same > > commit, it was a mistake in the first place. (It would also make trouble e.g. > > in Subversion, where tags are also directories.) > > Nope, this is not a solution but a wrong workaround. This works fine on > case-sensitive file systems and also on Windows if the refs are packed. And if the refs are not packed? There's no way this can work then. It's like trying to have a "foo.txt" and "Foo.txt" in the same folder, that can't be handled sanely by any tool either.
By the way, I'm not saying that EGit should not detect this and somehow work around it. I'm just saying that in addition to that, the repository should be corrected.
Wearing a random customer's hat, I would also remove one of the tags. But as a member of the Eclipse SDK team, I prefer to not touch the repository and keep this as a test case. > And if the refs are not packed? There's no way this can work then. EGit could just automatically perform the equivalent of "$ git pack-refs" after a fetch.
(In reply to comment #6) > Wearing a random customer's hat, I would also remove one of the tags. > > But as a member of the Eclipse SDK team, I prefer to not touch the repository > and keep this as a test case. I'd rather have a real (JUnit) test in the EGit repository for this. > > And if the refs are not packed? There's no way this can work then. > > EGit could just automatically perform the equivalent of "$ git pack-refs" after > a fetch. What if two such tags come with the same fetch? Then it's already too late because fetch will have tried to save the tags as two files in .git/refs and failed. The only way this would work is if fetch would directly write the tag into the pack-file. But I'm not sure it would be good to deviate from the C Git behavior in this.
> What if two such tags come with the same fetch? Then it's already too late > because fetch will have tried to save the tags as two files in .git/refs and > failed. Not if EGit behaves like git. Git doesn't fail on the second tag, it just shows a little message. On the command line, I can do the following, and then everything is fine: $ git fetch $ git pack-refs $ git fetch In EGit, I can't get rid of the error. Since EGit is not a low-level tool, it should just take care of the issue and pack the refs. It could show a message like in EGit 2.0 (see screenshot) on the first Fetch operation, but it should never show an error.
I got this error on OSX with a branch that was pushed from a Windows client (using git bash). When I pulled the first time, there was no problem (new branch). However, when I tried to fetch after new commits were pushed to that branch, I received the "lock fail" error for this branch. When I did "git pull" on the command line, I received the following: "From https://repo * [new branch] issues/example -> origin/issues/example Your configuration specifies to merge with the ref 'Issues/example' from the remote, but no such ref was fetched." I couldn't really find out why. Not sure if this is a problem with EGit. The only difference seems to be the lower/uppercase of the first character of the branch.
Created attachment 273267 [details] minimalistic demo project On Windows 7 using Oxygen 4.7.2 and git version 2.16.2.windows.1 unpack zip-file register git-repository in Eclipse Import project to Eclipse view history of this project open git-bash in parallel type: "git checkout Master" (explicitly wrong case) the command will succeed But Eclipse will constantly scan the history for the misstyped branch marker causing high CPU-load CPU-Load stops once you checkout the correctly spelled branch again.
