| 1 |
Michał Górny wrote: |
| 2 |
> Mirror clone |
| 3 |
> Single branch clone |
| 4 |
|
| 5 |
Look fine. |
| 6 |
|
| 7 |
|
| 8 |
> Shallow clone |
| 9 |
> ------------- |
| 10 |
> - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode), |
| 11 |
|
| 12 |
Hm, why is that? This seems like an unfortunate and inconvenient |
| 13 |
limitation which might actually reduce usefulness of shallow mode |
| 14 |
quite severely? :\ |
| 15 |
|
| 16 |
|
| 17 |
> - changing branches may be very inefficient (since it implies |
| 18 |
> re-fetching all objects implied by --depth 1), |
| 19 |
|
| 20 |
If it's the same local repo then at least in theory all existing |
| 21 |
blobs and trees don't strictly need to be transfered, only unseen |
| 22 |
ones and all the refs. But I'm not sure if git is so good at dealing |
| 23 |
with this - I haven't looked at exactly how packs are structured. |
| 24 |
|
| 25 |
|
| 26 |
> For example, if ebuilds sets EGIT_MIN_CLONE_MODE=single, and user sets |
| 27 |
> EGIT_CLONE_MODE=shallow, this single ebuild will be fetched |
| 28 |
> in single-branch mode. This can be used when build system operates |
| 29 |
> on repo history and doesn't work without it. |
| 30 |
|
| 31 |
I would prefer if I needed to allow such mode upgrades explicitly. |
| 32 |
|
| 33 |
|
| 34 |
> When mirror or single-branch mode is used on a shallow repository, |
| 35 |
> the repository is still marked 'shallow' even if the full history is |
| 36 |
> available. I don't know if this wouldn't break some of 'git foo' uses |
| 37 |
> in the checkout but that probably can't be predicted. Moreover, I don't |
| 38 |
> know if it is safe to remove 'shallow' after doing full-fetch in mirror |
| 39 |
> mode. |
| 40 |
|
| 41 |
If each mode uses a different remote name (but same URL) then I don't |
| 42 |
think anything can break. |
| 43 |
|
| 44 |
|
| 45 |
> When single-branch or shallow mode is used on a mirror-mode repository, |
| 46 |
> only the requested branch/tag is updated. The repository may no longer |
| 47 |
> be correctly synced to the remote. |
| 48 |
|
| 49 |
I think that's fine as long as only the package manager is expected |
| 50 |
to deal with these repos. Perhaps it would be nice to have a way to |
| 51 |
forcibly fetch using a tool in portage-utils or something. Dunno. |
| 52 |
|
| 53 |
|
| 54 |
> That's pretty much it. Most of the stuff I've tested proof-of-concept. |
| 55 |
> It may not work as well in the actual eclass. Any thoughts? |
| 56 |
|
| 57 |
I think most of it sounds very good. Thanks! |
| 58 |
|
| 59 |
|
| 60 |
//Peter |
Archives