Bug 384673 – Request: Modify sys-kernel/zen-sources-9999.ebuild to only git clone --depth 1

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Robert Cabrera 2011-09-27 15:35:13 UTC]

Could someone in charge please modify or add a flag to the sys-kernel/zen-sources-9999.ebuild so that it will only git clone --depth 1.

After many months of trying different kernel sources and finding none gave me the performance and responsiveness I had when running zen-sources previously, I decided to check out and unmask the sys-kernel/zen-sources-9999.ebuild.

What a disaster! The ebuild as currently written clones the entire tree not just the top-level as recommended on the Zen-kernel site. As a result I ended up downloading well over a gig and it took several hours just to try out a kernel!

This has to put a tremendous burden on their servers which explains why it's been down for long periods. It must cost a fortune to pay for that kind of bandwidth.

My suggestion is to add a flag that only clones to --depth 1 or make the default setting clone --depth 1 and add a flag for developers who want to clone the entire tree.

Thanks in advance.

Reproducible: Always

[Comment 1 Chí-Thanh Christopher Nguyễn 2011-10-04 12:38:03 UTC]

That can cause problems. If a later update includes a reverts of some older commit, then things may break.

[Comment 2 Markos Chandras (RETIRED) 2011-10-12 20:57:29 UTC]

I don't think it is safe to do that, like Chí-Thanh said, either

[Comment 3 Markos Chandras (RETIRED) 2011-10-17 18:45:33 UTC]

I added a "minimal" use flag which is enabled by default. Please test if it actually works and report bug here. Thank you

[Comment 4 Keshav Kini 2011-11-29 16:14:15 UTC]

(In reply to comment #1)
> That can cause problems. If a later update includes a reverts of some older
> commit, then things may break.

`git revert` only refers to the commit that is being reverted at the time the command is run. The resulting commit bears no actual reference to the original commit it is undoing, other than in the commit message. So there is no harm in pulling such a commit even if you do not have the original commit it is reverting (due to having a shallow clone locally). Is that what you meant by "things may break"?

[Comment 5 Keshav Kini 2012-03-07 11:41:25 UTC]

I finally tested this. It does not work.

> * The specific snippet of code:
> *       ${MOVE_COMMAND} "${EGIT_SOURCEDIR}" || die "${FUNCNAME}: sync to \"${EGIT_SOURCEDIR}\" failed";

The actual message:

> GIT NEW clone -->
>    repository:               git://zen-kernel.org/kernel/zen-stable.git
>    at the commit:            52cb5c09163d2b5b19b3da9f09479b7f48bab97d
>    branch:                   master
>    storage directory:        "/usr/portage/distfiles/egit-src/zen-stable"
>    checkout type:            bare repository
> Cloning into '/var/tmp/portage/sys-kernel/zen-sources-9999/work/linux-2.6.99-zen0'...
> fatal: attempt to fetch/clone from a shallow repository
> fatal: The remote end hung up unexpectedly
>  * ERROR: sys-kernel/zen-sources-9999 failed (unpack phase):
>  *   git-2_move_source: sync to "/var/tmp/portage/sys-kernel/zen-sources-9999/work/linux-2.6.99-zen0" failed

So it looks like the git-2 eclass doesn't support shallow clones (?).