1 |
Dnia 2014-10-05, o godz. 10:18:21 |
2 |
Dirkjan Ochtman <djc@g.o> napisał(a): |
3 |
|
4 |
> On Sat, Oct 4, 2014 at 2:00 AM, Rich Freeman <rich0@g.o> wrote: |
5 |
> > I was thinking that it might make more sense to just make things |
6 |
> > really simple and ONLY migrate the active tree into the starting git |
7 |
> > repository. That is, basically take the rsync tree, remove metadata, |
8 |
> > and do a git init. (Then follow that up with removing changelogs, |
9 |
> > cleaning up cvs headers, and so on.) |
10 |
> > |
11 |
> > A historical migration could be done in parallel and released a few |
12 |
> > hours later. However, it would not be a contiguous repository. That |
13 |
> > is, the converted active tree commit would not have any parents. If |
14 |
> > you wanted to have a contiguous tree you would need to splice in the |
15 |
> > historical migration with git replace. |
16 |
> |
17 |
> I think that would be sad. IMO there should be full history to the |
18 |
> default tree (even if we advocate shallow clones by default). Yes, the |
19 |
> history might not be perfect; people can splice in an improved history |
20 |
> later with git replace. I would be disappointed if the git hash for |
21 |
> the default tree doesn't represent (some version of) the full history. |
22 |
|
23 |
I see two issues with this: |
24 |
|
25 |
1. this will make the initial repo huge (~1.5G) and therefore hard to |
26 |
mirror. GitHub has a 'soft' limit of 1G. Other mirror providers may |
27 |
also be unhappy given the perspective of 1.5G and growing, compared to |
28 |
70M and growing with potential cutoff in future. |
29 |
|
30 |
2. Replacing the history with a better one would still keep the old |
31 |
commits. That is, after we fix the history properly, the repo grows |
32 |
another 1.5G, while the now-unused old 1.5G still needs to be kept. |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |