Hi,
2013/4/7 David Kastrup <address@hidden>:
Janek Warchoł <address@hidden> writes:
2013/4/7 David Kastrup <address@hidden>:
Packing actual executables could possibly also work with reasonable
overhead.
There would be an advantage to a repository storing _complete_ compiled
versions of LilyPond: it would make "git bisect" for the purpose of
finding a regression in code or documentation a snap.
Hmm.
Some time ago i've tried creating a repository containing lily builds,
but somehow i wasn't able to tell git to actually track all files - it
seemed that majority of them were ignored.
find -name .gitignore -delete
There is a wagonload of them in a typical LilyPond tree. Or:
The git add command can be used to add ignored files with the -f (force)
option.
That did the trick, i'm able to track things now.
However, the results aren't very encouraging - here are the stats of
the .git repository directory after several stages:
after first configure: 513 items, totalling 656.8 kB
after building master (25580682a): 5,010 items, totalling 59.2 MB
after building 473a73eeb (30 commits away): 5,377 items, totalling 91.4 MB
after building f1689df7a (1 commit away from master, and a small one)
5,580 items, totalling 112.3 MB
..so it's growing quite fast.
According to http://stackoverflow.com/a/3055693/2058424 (and the
linked email, over which i've skimmed) there may be some remedy for
this, but it's not plain to me how exactly it should be done, and i'm
out of time for testing now.
However, i'd be very interested in seeing a solution for this (i.e.
how to efficiently store lily executables in a repository).
best,
Janek