aboutsummaryrefslogtreecommitdiff
path: root/doc/devblog/day_271__parallel_get_groundwork.mdwn
blob: 7f7a3afbaa129af0edd2e12d32e52023397ea681 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
I've started work on [[todo/parallel_get]].
Today, laid the groundwork in two areas:

1. Evalulated the ascii-progress haskell library. It can display
   multiple progress bars in the terminal, portably, and its author
   Pedro Tacla Yamada has kindly offered to improve it to meet
   git-annex's needs.

   I ended up filing [10 issues](https://github.com/yamadapc/haskell-ascii-progress/issues)
   on it today, around 3 of the are blockers for git-annex using it.

2. Worked on making --quiet more quiet. Commands like rsync and wget
   need to have thier progress output disabled when run in parallel.

   Didn't quite finish this yet.

---

Yesterday I made some improvements to how git-annex behaves when it's
passed a massive number of directories or files on the command line.
Eg, when driven by xargs. There turned out to be some bugs in that
scenario.

One problem one I kind of had to paper over. While git-annex get
normally is careful to get the files in the same order they were listed on
the command line, it becomes very expensive to expand directories using
git-ls-files, and reorder its output to preserve order, when a large number
offiles are passed on the command line. There was a O(N*M) time blowup.

I worked around it by making it only preserve the order of the first 100
files. Assumption being that if you're specifying so many files on the
command line, you probably have less of an attachment to their ordering. :)