Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 255451 - Shallow clone of git repo in eclass
Summary: Shallow clone of git repo in eclass
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Tomáš Chvátal (RETIRED)
URL:
Whiteboard:
Keywords: InOverlay, InVCS
Depends on:
Blocks:
 
Reported: 2009-01-19 00:47 UTC by Maciej Mrozowski
Modified: 2009-03-19 11:54 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
perform shallow clone (giteclass.patch,350 bytes, patch)
2009-01-19 00:48 UTC, Maciej Mrozowski
Details | Diff
fallback behaviour (git.eclass.diff,1.11 KB, patch)
2009-03-18 22:49 UTC, Maciej Mrozowski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Mrozowski gentoo-dev 2009-01-19 00:47:14 UTC
So far git.eclass performs full bare clone of repository, which is unnecessary as it's being used only for fetch/export, and not for push/clone and repository history weights considerable amount of space - unnecessary in this case.
Attached trivial patch makes git eclass perform shallow bare clone.
Comment 1 Maciej Mrozowski gentoo-dev 2009-01-19 00:48:01 UTC
Created attachment 178944 [details, diff]
perform shallow clone
Comment 2 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2009-01-19 05:17:24 UTC
Thanks, unfortunately the git.eclass does not have a @MAINTAINER field so hopefully one of these guys will own it ;)
Comment 3 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2009-01-19 05:18:06 UTC
And a retired dev won't do it =/
Comment 4 Maciej Mrozowski gentoo-dev 2009-01-19 12:59:58 UTC
Well, 1st of all, it could be parametrized by some variable (whether to do shallow clone or full), as somebody may actually want full clone.
Comment 5 Steve L 2009-01-21 05:35:45 UTC
I'd say this is so trivial, stick it in as-is, since it will save everyone bandwidth, and then sort out the variable (it's easy enough for portage users to set it per-pkg.)
Comment 6 Maciej Mrozowski gentoo-dev 2009-02-05 22:56:10 UTC
So... any volunteers? :)
Comment 7 Tomáš Chvátal (RETIRED) gentoo-dev 2009-02-19 17:08:54 UTC
In the tree. Fixed. Added myself as a maintainer.
Comment 8 Fernando J. Pereda (RETIRED) gentoo-dev 2009-02-19 19:47:43 UTC
Your change is broken, revert, test and then commit again after you sort out the issues you created.

- ferdy

Comment 9 Fernando J. Pereda (RETIRED) gentoo-dev 2009-02-19 19:48:48 UTC
(forgot to reopen)

Also, if you can't work out what kind of issues it creates, let me know and I'll try to get some time to explain them.

- ferdy

Comment 10 Maciej Mrozowski gentoo-dev 2009-02-19 21:55:16 UTC
Please don't waste your precious "Gentoo time" on clicking bugzilla and next time right away enlighten us all about this major breakage it causes. (apart from that it no longer allows commiting to this clone as it's shallow clone).
Comment 11 Fernando J. Pereda (RETIRED) gentoo-dev 2009-02-19 22:15:49 UTC
@reavertm: I don't have time to enlighten someone lacking as much knowledge as you.

For those that have the very basics of git: this breaks if different ebuilds use the same repository but go 'back' in time. It is a very reasonable use case and the eclass supports (and has always supported) it. In actual fact, it is one of the design decissions of the eclass.

Really, this should have been obvious for anyone reading the whole eclass even though I admit it is not explicitly stated anywhere

Please, do revert it.

- ferdy

Comment 12 Maciej Mrozowski gentoo-dev 2009-02-19 23:04:46 UTC
> "I don't have time to enlighten someone lacking as much knowledge as
you."

Obviously :)
Like EGIT_BRANCH/EGIT_TREE ever worked flawlessly...

cheers
Comment 13 Tomáš Chvátal (RETIRED) gentoo-dev 2009-02-28 08:42:01 UTC
@Ferdy
so actualy you are saying:
Reverting the patch cause it breaks history for really really limited set of ebuilds, where the global variable can be REDEFINED?
Why, now it consumed much less bandwitch and actualy worked faster.

I really tested on bunch of X packages and some various live things before commiting and it worked pretty nicely.
I would say that ebuilds you take as measure for stating that you could go back in history should redefine the command rather than having eclass that must clone all stuff.
Comment 14 Fernando J. Pereda (RETIRED) gentoo-dev 2009-02-28 12:21:22 UTC
I'm saying you broke a very useful and legit case for no good reason. And you didn't even bothered to check the tree for such cases nor you did tell anybody.

Breaking crap without telling people is just silly.

Shallow clone already existed when Donnie and I created git.eclass, there's reasons we left that out (among other stuff like automatic repack and prune).

Really, revert it.

- ferdy

Comment 15 Łukasz Damentko (RETIRED) gentoo-dev 2009-03-17 22:33:03 UTC
Moving back to wranglers since Ferdy left Gentoo.
Comment 16 Tomáš Chvátal (RETIRED) gentoo-dev 2009-03-17 22:36:42 UTC
yea, yea, ... so far it works in x11 overlay with no issues being reported.
Comment 17 Chí-Thanh Christopher Nguyễn gentoo-dev 2009-03-18 17:18:25 UTC
Please revert this change, it breaks building specific git revisions in git ebuilds. For example x11-base/nouveau-drm in sunrise now fails with

>>> Unpacking source...
 * git update start -->
 *    repository: git://anongit.freedesktop.org/git/mesa/drm
 *    local clone: /usr/portage/distfiles/git-src/nouveau-drm
 *    committish: 3dcc742a9fdd909d3a7ebb2f634a6b2759c3dbd4
fatal: not a tree object
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
>>> Unpacked to /var/tmp/portage/x11-base/nouveau-drm-20090228/work/drm
/var/tmp/portage/x11-base/nouveau-drm-20090228/temp/environment: line 4018: cd: /var/tmp/portage/x11-base/nouveau-drm-20090228/work/drm/linux-core: No such file or diy
sed: can't read Makefile: No such file or directory
cp: cannot stat `/var/tmp/portage/x11-base/nouveau-drm-20090228/work/drm/tests/*.c': No such file or directory

for one user.
Comment 18 Maciej Mrozowski gentoo-dev 2009-03-18 22:49:29 UTC
Created attachment 185466 [details, diff]
fallback behaviour

Perform shallow clone when EGIT_BRANCH and EGIT_TREE is set to master (ebuild is tracking only latest changes).
Reverting patch is not an option - we won't keep useless git history for every package just because of few ebuilds picking specific commits.
Comment 19 Tomáš Chvátal (RETIRED) gentoo-dev 2009-03-19 09:10:22 UTC
Agree with reaver, fallback added into x11 overlay where is tested new soon-to-be-added git.eclass for testing purposes test it with x11 overlay added and report how it works.
Comment 20 Chí-Thanh Christopher Nguyễn gentoo-dev 2009-03-19 11:41:12 UTC
Thank you for this fix. But please, revert the change in portage until the git.eclass from x11 overlay enters the tree.
Comment 21 Tomáš Chvátal (RETIRED) gentoo-dev 2009-03-19 11:54:41 UTC
Added reavertms patch to the eclass in the tree for now.