Summary: | git-r3.eclass has sandbox violations due to shallow clones of local repos | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | eroen <erikdenstore+gbugs> |
Component: | Eclasses | Assignee: | Michał Górny <mgorny> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | qa, zerochaos |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=486074 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
eroen
2013-11-14 19:21:47 UTC
I will try to fix it this weekend. If you could try to provide a patch, it would make things faster. I think we can simply detect local repo URIs and disable shallow clones then (since git will hardlink stuff anyway). (In reply to Michał Górny from comment #1) > I will try to fix it this weekend. If you could try to provide a patch, it > would make things faster. I think we can simply detect local repo URIs and > disable shallow clones then (since git will hardlink stuff anyway). So if shallow clone doesn't work on googlecode, and doesn't work local, why on earth is it the default??? This is just silly honestly. Why is git trying to write to the source repo? Clearly it can't do this if the repo is not local so why is it doing it when it is? I'm not sure if this is a git bug or a git-r3 bug but I can say either way these defaults suck, and if it doesn't get fixed to not break so much I'm going to undeprecate git-2 so we can have something that actually works by default. (In reply to Rick Farina (Zero_Chaos) from comment #2) > (In reply to Michał Górny from comment #1) > > I will try to fix it this weekend. If you could try to provide a patch, it > > would make things faster. I think we can simply detect local repo URIs and > > disable shallow clones then (since git will hardlink stuff anyway). > > So if shallow clone doesn't work on googlecode, and doesn't work local, why > on earth is it the default??? This is just silly honestly. Please tell me, how many ebuilds in the tree use *local* repos? There are a few using Google Code but the majority *benefits* from it. This simply doesn't make sense. > Why is git > trying to write to the source repo? Clearly it can't do this if the repo is > not local so why is it doing it when it is? I'm not sure if this is a git > bug or a git-r3 bug I have no idea if it's a bug or feature. Git usually tries to hardlink local repos to the clones to save space, and it seems that '--depth 1' confuses it. I will look into it *when I have time*. > but I can say either way these defaults suck, and if it > doesn't get fixed to not break so much I'm going to undeprecate git-2 so we > can have something that actually works by default. Thanks for your professional opinion and a threat. Working for Gentoo is always a pleasure. (In reply to Michał Górny from comment #3) > (In reply to Rick Farina (Zero_Chaos) from comment #2) > > (In reply to Michał Górny from comment #1) > > > I will try to fix it this weekend. If you could try to provide a patch, it > > > would make things faster. I think we can simply detect local repo URIs and > > > disable shallow clones then (since git will hardlink stuff anyway). > > > > So if shallow clone doesn't work on googlecode, and doesn't work local, why > > on earth is it the default??? This is just silly honestly. > > Please tell me, how many ebuilds in the tree use *local* repos? There are a > few using Google Code but the majority *benefits* from it. This simply > doesn't make sense. In the tree, almost none. But things like chromeos and developers often use ebuilds with local repos. git-r3 basically makes it impossible for a lot of developers right now, yet you were kind enough to deprecate git-r2. > > > Why is git > > trying to write to the source repo? Clearly it can't do this if the repo is > > not local so why is it doing it when it is? I'm not sure if this is a git > > bug or a git-r3 bug > > I have no idea if it's a bug or feature. Git usually tries to hardlink local > repos to the clones to save space, and it seems that '--depth 1' confuses > it. I will look into it *when I have time*. If there are still bugs this significant, then git-r2 shouldn't be deprecated as CLEARLY git-r3 is unable to replicate it's feature set. > > > but I can say either way these defaults suck, and if it > > doesn't get fixed to not break so much I'm going to undeprecate git-2 so we > > can have something that actually works by default. > > Thanks for your professional opinion and a threat. Working for Gentoo is > always a pleasure. If you feel it is a threat to have a working gentoo then you are right, I'm directly threatening you personally. Otherwise, like every other sane person, when you deprecate an old eclass with a new eclass please be sure it is actually better. Thus far you have deprecated an eclass with almost no bugs with one that has caused nothing but problems. Not only were you nice enough to deprecate a working eclass, you then proceeded to add in inherit for your broken eclass into the working eclass which in the process, obviously broke it as well. This is not how gentoo works, the only reason you haven't been smacked down by QA is because there is no QA in gentoo. In two weeks, as per gentoo policy, I'm going to undeprecate git-2 and remove the inherit for git-r3 unless the defaults in git-r3 work for local and googlecode. This is not a threat, I'm not going to touch your shiny new eclass, I'm just going to unbreak the previously working eclass. I would love it if git-r3 replaced git-2, but with your current attitude towards bug reports, I don't honestly think that is ever going to happen. My attitude is not 'against bug reports' but against your attitude towards me. Believe me, there is a difference between reporting a bug and your monologues. + 15 Nov 2013; Michał Górny <mgorny@gentoo.org> git-r3.eclass: + Use shallow clones for local repos. Bug #491260. Please try now. Local repos in the configurations I could think off work well now. Thank you! :) (In reply to Rick Farina (Zero_Chaos) from comment #2) > Why is git > trying to write to the source repo? Clearly it can't do this if the repo is > not local so why is it doing it when it is? I'm not sure if this is a git > bug or a git-r3 bug (..snip..) Git contributor here. I think I'm the one that made this change in Git. I believe we do not ever state that "for a fetch/clone request, git promises not to write anything in the repo". We could use $TMPDIR for these temporary files, but that would be the last resort, and I'm going to make that change for read-only repos. But that does not help this case. Fix your sandbox rules. |