Created attachment 287109 [details, diff] patch to use git.eclass's default EGIT_DIR when appropriate (as discussed in #gentoo-desktop) One highly annoying factor in migrating from git.eclass to git-2.eclass is that the git repositories which git.eclass, by default, stores under ${DISTDIR}/git-src, all have to be redownloaded to new directories under ${DISTDIR}/egit-src. It would be much more logical if git-2's algorithm for setting EGIT_DIR was instead the following: if EGIT_DIR is not set and git.eclass's default EGIT_DIR exists (i.e. the ebuild had previously used git.eclass) and git-2.eclass's default EGIT_DIR does *not* exist (i.e. either the ebuild had not previously been upgraded to use git-2.eclass, or the user had not had the chance to download the sources to ${DISTDIR}/egit-src) then set EGIT_DIR to the default git.eclass value. The attached patch does so.
Tomas, what was the rationale for moving EGIT_DIR? As I see it, this looks like crawling back. As I see it, we should just use one EGIT_DIR location and: - if checkout in both new and old location exists, rm -r the old one; - if checkout exists only in old location, mv or git clone it (the latter should be safer if the checkout can be broken somehow). I like the 'git-src' location more, to be honest but it is likely that 'egit-src' has now newer checkouts, so switching back would result in re-downloading new commits.
As i wrote multiple times this bug was WONTFIX. And i explained it on -dev mailing list and on bugs, just search it. It failed to work on some checkout done by old git.eclass, so the directory was renamed, if users trust that the git thingu won't fail for them they are free to move that clone thir themselves, but the eclass should not do it. But if donnie wants to mess with it and implement moving the directories in the eclass he should rather mv git-src/something egit-src/something prior the update rather than working in the old location anyway.
Created attachment 287167 [details, diff] Try to migrate git.eclass checkouts to the new eclass.
(In reply to comment #3) > Created attachment 287167 [details, diff] > Try to migrate git.eclass checkouts to the new eclass. This is my suggestion. It is very simple -- on initial checkout tries to find the old clone using the same rules as ol' git.eclass. If it does find one, it prepends it to EGIT_REPO_URI. Thus, the eclass will first try to clone the old clone. If it fails, it will fallback to fetching from remote. This should be a pretty safe way. One disadvantage it has is that the package needs to emerged again to fetch changes from remote but I think it's basically one-time issue not worth addressing. If we go further this way, I can prepare a patch to remove old git-src clones.
The patches have been sent to gentoo-dev for review already and should be in tree soon.
Ok, should be fixed now. Feedback appreciated.