Bug 360669

Comment 1 Markus Keller 2012-07-05 09:41:51 EDT

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

Comment 2 Robin Stocker 2012-07-06 04:54:38 EDT

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.)

Comment 3 Dani Megert 2012-07-06 05:01:12 EDT

(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.

Comment 4 Robin Stocker 2012-07-06 07:02:53 EDT

(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.

Comment 5 Robin Stocker 2012-07-06 07:06:20 EDT

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.

Comment 6 Markus Keller 2012-07-09 09:22:21 EDT

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.

Comment 7 Robin Stocker 2012-07-10 06:41:21 EDT

(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.

Comment 8 Markus Keller 2012-07-10 07:00:53 EDT

> 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.

Comment 9 Matthias Schoettle 2015-04-03 12:03:34 EDT

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.

Comment 10 Holger Klene 2018-03-23 04:00:10 EDT

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.