<guardian>
ddfreyne: I wish we could pin items when recompiling during dev
<guardian>
ddfreyne: that would be very handy
<bobthecow>
guardian: pin?
<guardian>
as in pinning
<guardian>
"pin this item, don't recompile it"
<bobthecow>
posting to pinterest?
<guardian>
"keep previous compile"
<bobthecow>
you just need to spell that "don't change things"
<bobthecow>
for most sites where things recompiled too much, i was doing something dumb to make things depend on things they didn't actually depend on.
<ddfreyne>
guardian: I'd rather spend time on improving the dependency tracking
<ddfreyne>
(It's more work, but it is more correct)
<bobthecow>
what he said :)
<ddfreyne>
bobthecow: I've been playing around with parsing the Rules file to extract information about the patterns and their steps, and use that to decide whether to recompile items or not
<ddfreyne>
bobthecow: Currently, nanoc takes *all* items and filters out the ones that do not have to be recompiled.
<ddfreyne>
bobthecow: I want to change that, so that nanoc takes the list of all *changes* and finds the matching items for that.
<bobthecow>
like tup.
<ddfreyne>
bobthecow: Yes, very much so
<bobthecow>
making arrows go the other way.
<ddfreyne>
(nanoc is already pretty similar to tup, because the arrows already go in the opposite way)
<ddfreyne>
bobthecow: The only thing I am unsure about is how to figure out, efficiently, what files have changed in content/
<ddfreyne>
With a DB data source, it is easy (WHERE updated_at > blah)
<ddfreyne>
I guess just looping through all files, getting their mtimes and comparing them.
<ddfreyne>
nanoc 4.x will need a way to efficiently hook into a listener, so that data sources aren't only meant for *pulling* data from, but that they can also *push* changes to nanoc