1 |
On 24/02/14 04:00 PM, Michał Górny wrote: |
2 |
> Dnia 2014-02-24, o godz. 21:13:15 |
3 |
> Peter Stuge <peter@×××××.se> napisał(a): |
4 |
> |
5 |
>> Michał Górny wrote: |
6 |
>>> Shallow clone |
7 |
>>> ------------- |
8 |
>>> - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode), |
9 |
>> |
10 |
>> Hm, why is that? This seems like an unfortunate and inconvenient |
11 |
>> limitation which might actually reduce usefulness of shallow mode |
12 |
>> quite severely? :\ |
13 |
> |
14 |
> Limitation of git design. You can only fetch remote refs, you can't |
15 |
> fetch an arbitrary hash. And since we don't download the whole history, |
16 |
> we can't use a hash that was past 'depth' of the branch/tag clone. So |
17 |
> in order to use an arbitrary hash, we actually have to download |
18 |
> the history. |
19 |
|
20 |
Perhaps you could have EGIT_FETCH_REF and EGIT_CHECKOUT? |
21 |
|
22 |
>>> - changing branches may be very inefficient (since it implies |
23 |
>>> re-fetching all objects implied by --depth 1), |
24 |
>> |
25 |
>> If it's the same local repo then at least in theory all existing |
26 |
>> blobs and trees don't strictly need to be transfered, only unseen |
27 |
>> ones and all the refs. But I'm not sure if git is so good at dealing |
28 |
>> with this - I haven't looked at exactly how packs are structured. |
29 |
> |
30 |
> It's not good at all. In fact, if you try to update a shallow clone |
31 |
> with 'git fetch --depth 1', it's going to refetch all the objects |
32 |
> (while plain 'git fetch' only downloads new objects). It's just another |
33 |
> limitation of protocol that we can't do much about. |
34 |
|
35 |
Can't you use `git fetch` as usual to download old..new commits only? |
36 |
This wouldn't help with switching branches though. |
37 |
|
38 |
>> I would prefer if I needed to allow such mode upgrades explicitly. |
39 |
> |
40 |
> That sounds like a lot ebuilds failing, requesting you to explicitly |
41 |
> change the mode. For example, all Google Code hosted repositories |
42 |
> do not support shallow mode. Some projects may require single-branch |
43 |
> mode to handle their 'git log' play. |
44 |
|
45 |
Perhaps EGIT_CLONE_MODE could be a USE_EXPAND (yes, another one)? |
46 |
|
47 |
>>> When mirror or single-branch mode is used on a shallow repository, |
48 |
>>> the repository is still marked 'shallow' even if the full history is |
49 |
>>> available. I don't know if this wouldn't break some of 'git foo' uses |
50 |
>>> in the checkout but that probably can't be predicted. Moreover, I don't |
51 |
>>> know if it is safe to remove 'shallow' after doing full-fetch in mirror |
52 |
>>> mode. |
53 |
|
54 |
git fetch --unshallow according to |
55 |
https://stackoverflow.com/questions/6802145/convert-shallow-clone-to-full-clone |