| Summary: | git.eclass and clones being both shallow and bare | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Eclasses | Assignee: | Tomáš Chvátal (RETIRED) <scarabeus> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | minor | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
The patch to git.eclass
Small fix |
||
Created attachment 220867 [details, diff]
The patch to git.eclass
Created attachment 220963 [details, diff]
Small fix
Well, now I think shallow clones are useless after all. On first update, git fetches a lot of data after all -- and using them is really annoying. Thus, I think you might reject the bug. |
The current code for dealing with git bare repository cloning does doesn't play nice with shallow copies. Moreover, it lacks a '|| die' to the 'git clone' command. I've created a simple proof-of-concept patch which allows git to deal fine with clones being both shallow and bare at the same time but I'm not sure whether it the correct approach. It replaces the 'git clone' approach with rsyncing the bare copy into '.git' subdirectory of ${S}, and then uses 'git init' to reinit the repo (it is required for git to work with it) and 'git checkout' to get the required files.