Hi, David Roundy <[EMAIL PROTECTED]> writes: > (And I'd want to do a behavior change in smart_diff, so if you can wait on > that until we've had time to talk, that would be great.) I have noticed something in that respect, and I'd like such a change myself, too. If I understood correctly, and also my intuition would be to:
1) smart_diff doesn't need to know about either LookForAdds or Summary/NoSummary -- afterall, if the (extraneous) information is not used in the upper layer, I think it should stay unevaluated so no overhead incurred (the Slurpy principle). - It seems Summary is used to ignore file content on addfiles. - LookForAdds is used to avoid those files that are only in working. Now, I haven't looked how addfile patches actually work, but I'd guess that smart_diff doesn't look at pending, so any "addfile" patches in its output would indicate an untracked file (that would be currently excluded without LookForAdds). (I've quickly looked at get_unrecorded_private and what I see seems to support that theory.) This means the upper layer has enough information to filter whatever it wants to (in this case, I suppose get_unrecorded is the user that wants that kind of handling for LooksForAdds, or potentially even higher the stack -- but in that case, get_unrecorded might need to mark up the patches as "automatic" and "from pending"). 2) There is still the issue of IgnoreTimes: We can do a similar thing like with Compression, only passing in the information whether to honour or ignore timestamps. However, if we go one further layer up, it might be worth to start thinking how to concisely combine these minimalistic pieces of information into slightly larger blocks. On the other hand, I probably shouldn't worry about that just yet, since it's hard to tell how will things end up like. Maybe just tuple the various types, and if a certain tuple turns out to be common and cohesive, newtype it and add a [DarcsFlag] -> WhateverNewType function? Well, I've just went a little wild-guessing on your intentions. I'll wait with doing any coding till I hear from you on what you have actually intended. I've just been thinking that it might save time if I guess rightly (or give an alternative viewpoint if I haven't). Yours, Petr. -- Peter Rockai | me()mornfall!net | prockai()redhat!com http://blog.mornfall.net | http://web.mornfall.net "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton on the subject of C program indentation _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
