| 1 |
On Wed, Dec 19, 2018 at 8:43 PM Kent Fredric <kentnl@g.o> wrote: |
| 2 |
> |
| 3 |
> I suspect a published list of SHA1's broken down by time might also |
| 4 |
> help here in conjunction with passing required ones as "refspec" values |
| 5 |
> to fetch, which would also approximate the bundle strategy, albeit |
| 6 |
> using substantially less server-side storage space. |
| 7 |
|
| 8 |
I'm not sure how necessary this is, but another way to do this is to |
| 9 |
just use tags, perhaps date-based (eg year-month). Perhaps this could |
| 10 |
be combined with some level of QA as well to ensure the tree is clean |
| 11 |
at the time it was tagged. From the command line this would be |
| 12 |
simpler than copy/pasting hashes from some webpage, but it obviously |
| 13 |
clutters the repo. Granted, it isn't much clutter if you only do it |
| 14 |
monthly. |
| 15 |
|
| 16 |
Git fetch does not seem to support any kind of relative refspec. You |
| 17 |
need a hash/branch/tag/ref. Git ls-remote just lists refs and not |
| 18 |
history. |
| 19 |
|
| 20 |
If super-unreliable connections are the concern it probably would be |
| 21 |
cleaner to just use the previous suggestion of providing bundles with |
| 22 |
resume support. They can be downloaded and then pulled/fetched from. |
| 23 |
Do we really have that much of a need for this? |
| 24 |
|
| 25 |
-- |
| 26 |
Rich |
Archives