Community
Participate
Working Groups
git://git.eclipse.org/gitroot/equinox/rt.equinox.framework.git contains tags R36x_v20110210 and r36x_v20110210. The tags only differ in casing, which causes trouble when the repository is cloned on a case-insensitive file system: $ git pull From git://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] r36x_v20110210 -> r36x_v20110210 From git://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] R36x_v20110210 -> R36x_v20110210 Current branch R3_6_maintenance_Java7 is up to date. The next pull command shows the same messages again. R36x_v20110210 is used in the R3_6_2 version of core.map, so this needs to stay. But r36x_v20110210 is bad and should be deleted.
I clone it on my Mac, which has a case insensitive file system, without error. What git impl/version are you using?
The following worked fine on a Windows 7 system. hargrave@WIN-0SDMRKH3UQC ~ $ git --version git version 1.7.5.1 hargrave@WIN-0SDMRKH3UQC ~ $ mkdir git hargrave@WIN-0SDMRKH3UQC ~ $ cd git hargrave@WIN-0SDMRKH3UQC ~/git $ git clone git://git.eclipse.org/gitroot/equinox/rt.equinox.framework.git Cloning into rt.equinox.framework... remote: Counting objects: 63249, done. remote: Compressing objects: 100% (15283/15283), done. remote: Total 63249 (delta 28034), reused 61142 (delta 26781) Receiving objects: 100% (63249/63249), 20.20 MiB | 702 KiB/s, done. Resolving deltas: 100% (28034/28034), done. hargrave@WIN-0SDMRKH3UQC ~/git $ Have you tried running git gc on your repo?
For what it's worth, I can reproduce the behavior described in comment 0 on Win XP Professional. $ git pull Password: remote: Counting objects: 254, done. remote: Compressing objects: 100% (135/135), done. remote: Total 140 (delta 115), reused 0 (delta 0) Receiving objects: 100% (140/140), 10.75 KiB, done. Resolving deltas: 100% (115/115), completed with 43 local objects. From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new branch] R3_6_maintenance_Java7 -> origin/R3_6_maintenance_Java7 5631c65..0673fde R3_7_maintenance -> origin/R3_7_maintenance 7d9e3b9..54d074e hargrave/osgi44 -> origin/hargrave/osgi44 b7a97f3..1942955 master -> origin/master * [new tag] R36x_v20111004-1525 -> R36x_v20111004-1525 * [new tag] R37x_v20111007-1209 -> R37x_v20111007-1209 * [new tag] R3_7_1 -> R3_7_1 * [new tag] r36x_v20110210 -> r36x_v20110210 * [new tag] v20111003-1644 -> v20111003-1644 * [new tag] v20111010-1614 -> v20111010-1614 From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] R36x_v20110210 -> R36x_v20110210 * [new tag] R37x_v20111004-1249 -> R37x_v20111004-1249 * [new tag] R37x_v20111005-1434 -> R37x_v20111005-1434 Already up-to-date. $ git pull Password: From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] r36x_v20110210 -> r36x_v20110210 From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] R36x_v20110210 -> R36x_v20110210 Already up-to-date. $ git pull Password: From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] r36x_v20110210 -> r36x_v20110210 From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] R36x_v20110210 -> R36x_v20110210 Already up-to-date. $ git --version git version 1.7.5.1 Also, the results of "git tag" show R36x_v20110210 -> R36x_v20110210 but not r36x_v20110210 -> r36x_v20110210.
(In reply to comment #3) > For what it's worth, I can reproduce the behavior described in comment 0 on Win > XP Professional. > $ git pull > Password: > remote: Counting objects: 254, done. > remote: Compressing objects: 100% (135/135), done. > remote: Total 140 (delta 115), reused 0 (delta 0) > Receiving objects: 100% (140/140), 10.75 KiB, done. > Resolving deltas: 100% (115/115), completed with 43 local objects. > From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework > * [new branch] R3_6_maintenance_Java7 -> origin/R3_6_maintenance_Java7 > 5631c65..0673fde R3_7_maintenance -> origin/R3_7_maintenance > 7d9e3b9..54d074e hargrave/osgi44 -> origin/hargrave/osgi44 > b7a97f3..1942955 master -> origin/master > * [new tag] R36x_v20111004-1525 -> R36x_v20111004-1525 > * [new tag] R37x_v20111007-1209 -> R37x_v20111007-1209 > * [new tag] R3_7_1 -> R3_7_1 > * [new tag] r36x_v20110210 -> r36x_v20110210 > * [new tag] v20111003-1644 -> v20111003-1644 > * [new tag] v20111010-1614 -> v20111010-1614 > From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework > * [new tag] R36x_v20110210 -> R36x_v20110210 > * [new tag] R37x_v20111004-1249 -> R37x_v20111004-1249 > * [new tag] R37x_v20111005-1434 -> R37x_v20111005-1434 > Already up-to-date. > $ git pull > Password: > From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework > * [new tag] r36x_v20110210 -> r36x_v20110210 > From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework > * [new tag] R36x_v20110210 -> R36x_v20110210 > Already up-to-date. > $ git pull > Password: > From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework > * [new tag] r36x_v20110210 -> r36x_v20110210 > From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework > * [new tag] R36x_v20110210 -> R36x_v20110210 > Already up-to-date. > $ git --version > git version 1.7.5.1 > Also, the results of "git tag" show R36x_v20110210 -> R36x_v20110210 but not > r36x_v20110210 -> r36x_v20110210. Running "git gc", as suggested in comment 2, appears to have resolved the issue on my system. $ git gc Counting objects: 63308, done. Delta compression using up to 2 threads. Compressing objects: 100% (14440/14440), done. Writing objects: 100% (63308/63308), done. Total 63308 (delta 28054), reused 62779 (delta 27670) Removing duplicate objects: 100% (256/256), done. $ git pull Password: From ssh://git.eclipse.org/gitroot/equinox/rt.equinox.framework * [new tag] r36x_v20110210 -> r36x_v20110210 Already up-to-date. $ git pull Password: Already up-to-date.
(In reply to comment #4) > Running "git gc", as suggested in comment 2, appears to have resolved the issue > on my system. git gc will pack the tags and remove them from the file system which is why it solves the problem. There are a number of r3* and R3* tags which may "overlap". And they are historical. Removing old tags seems risky. Since git gc will solve the issue on local repos, I would suggest it is the proper workaround.
(In reply to comment #5) > (In reply to comment #4) > > Running "git gc", as suggested in comment 2, appears to have resolved the issue > > on my system. > > git gc will pack the tags and remove them from the file system which is why it > solves the problem. > > There are a number of r3* and R3* tags which may "overlap". And they are > historical. Removing old tags seems risky. Since git gc will solve the issue on > local repos, I would suggest it is the proper workaround. I agree with BJ that this is an acceptable work around. I am wondering if the issue is more prevalent when cloning the repository with eGit. I am not sure I agree that this r36x_v20110210 tag is dangerous to delete. It seems to be a mistake that it was there to begin with. It is on a commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R3_6_maintenance&id=e6b7d2c3c859f722b8acd1c9f95254b5f4293f1d There are many other tags on this commit. I think it would be safe to delete this tag myself.
Unfortunately, the "git gc" solution cannot be performed via EGit. Currently, everyone who checks out the repo on Windows and then tries to pull gets a r36x_v20110210 : r36x_v20110210 [rejected] message (every time). And I don't know if EGit fully supports the packed refs file format. This is the only tag with overlapping versions. I still think this should be fixed in the repo.
(In reply to comment #7) > Unfortunately, the "git gc" solution cannot be performed via EGit. Currently, > everyone who checks out the repo on Windows and then tries to pull gets a Are you saying that eGit offers no way to gc the repo? This seems like an important deficiency.
(In reply to comment #8) > Are you saying that eGit offers no way to gc the repo? This seems like an > important deficiency. JGit itself doesn't completely implement 'gc'. There is partial support but it's still incomplete.
(In reply to comment #6) > There are many other tags on this commit. I think it would be safe to delete > this tag myself. How do you know that no one is using this tag? Even on case insensitive file systems, these are different tags: $ git log -1 R36x_v20110210 commit 50bdbc2c18bd697082cfdb2f545981b471c9b0e6 Author: Thomas Watson <twatson> Date: Mon Nov 1 17:46:25 2010 +0000 Bug 328975 - [Webapp] Possible security issue with JSP code exposure. $ git log -1 r36x_v20110210 commit e6b7d2c3c859f722b8acd1c9f95254b5f4293f1d Author: DJ Houghton <dj> Date: Thu Oct 7 16:06:26 2010 +0000 Bug 327233 - p2 and equinox feature versions need to be incremented in 3.6.2 stream It is bad form to delete a published tag since someone can depend upon it. But, this tag was migrated from CVS and someone can always get it from CVS assuming the foundation promised to always maintain the CVS repos in read-only form in perpetuity. Also, this is really a one time fix. There is nothing to stop tags in the future from causing this. You really need a server-side hook to enforce this constraint. (In reply to comment #7) > This is the only tag with overlapping versions. I still think this should be > fixed in the repo. Shouldn't we then also normalize all the r3* and R3* tags to all use R or r?
Tags should indeed not be changed in general, so I wouldn't "correct" other tags. Maybe best would be to just rename the tag to r36x_v20110210a. Chances are very small that someone really needs this tag and not the one that was used in 3.6.2. > Also, this is really a one time fix. There is nothing to stop tags in the > future from causing this. You really need a server-side hook to enforce this > constraint. Yes, but the tags are not freely chooseable anyway, since they're mostly used as bundle qualifiers. Once a format is chosen, you can't jump back and forth. Conflicts only occur if someone or something did something wrong.
(In reply to comment #11) > Yes, but the tags are not freely chooseable anyway, Of course the tags can be freely named. Without a server-side hook, I can use any tag name I want. > since they're mostly used > as bundle qualifiers. Once a format is chosen, you can't jump back and forth. > Conflicts only occur if someone or something did something wrong. That is the whole point of the server-side hook: to enforce the desired invariants on ref names. This all happened because of a human mistake in tagging in CVS. It will happen again in git. ----- I did an experiment and it seems the issue is mostly because egit/jgit unpacks all refs when cloning a repo. Even if the remote repo already has packed-refs. However, if you clone from the command line, or gc from the command line after using egit to clone, egit/jgit seems to handle the packed-refs just fine. I have no idea why egit/jgit insists on unpacking the refs when cloning...
(In reply to comment #12) > I have no idea why egit/jgit insists on unpacking the refs when cloning... Thanks for the investigations. Filed bug 360536 for EGit.
Sorry, I filed bug 360669 for EGit.
I am going to close this as wontfix for now. I think the workaround is sufficient. Please reopen if you feel otherwise, but I am not sure we would want to fix this in the git repo.
