Re: Lost Repository Was: Removing git-annex Repo

2011-12-05 Thread Joey Hess
Klaus Ethgen wrote: Can you check out the git-annex branch and run git-log on uuid.log, and see what the most recent change to it looked like? It is an update. After that I revert this update and the next time it will purged again. It sort of sounds as if you are checking out the

Re: Lost Repository Was: Removing git-annex Repo

2011-12-05 Thread Klaus Ethgen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Mo den 5. Dez 2011 um 17:19 schrieb Joey Hess: Klaus Ethgen wrote: Can you check out the git-annex branch and run git-log on uuid.log, and see what the most recent change to it looked like? It is an update. After that I revert this

Re: New integration branch

2011-12-05 Thread Joey Hess
Adam Spiers wrote: 9c87f2352214175de307efedb8fd93889a26afbc        Can you give an example of when this is needed? I can't remember but I definitely saw it happen at least once :-/ My worry is that, since that really shouldn't happen AFIACS, you were actually seeing a bug. Either that or

Re: alternative mechanisms for including config

2011-12-05 Thread Joey Hess
Adam Spiers wrote: This may be a good time to discuss the design of the `include' parameter. When you were deciding what its value should be, I guess there were at least three possibilities: (1) a chunk of shell-code which returns the actual shell-code to include (2) a

Re: New integration branch

2011-12-05 Thread Adam Spiers
On Mon, Dec 5, 2011 at 5:38 PM, Joey Hess j...@kitenet.net wrote: Adam Spiers wrote: 9c87f2352214175de307efedb8fd93889a26afbc        Can you give an example of when this is needed? I can't remember but I definitely saw it happen at least once :-/ My worry is that, since that really

Re: New integration branch

2011-12-05 Thread Joey Hess
Joey Hess wrote: It could well not be. mr list -j 10 runs in the same time as mr list -j 1, suggesting the overhead is in something else than actually running the shell. Whoops, bad benchmark, -j comes before action. Anyway, yes, without any calls to system(), mr list takes just 0.35 seconds.

Re: New integration branch

2011-12-05 Thread Joey Hess
Joey Hess wrote: Moving the git_test etc into perl code would be one way to speed it up for the common case. Adding a special case optimisation to avoid the shell for true and false brings mr list down from 8.50 to 1.81 seconds. The remaining time is here spent running skip tests, I have a