Junio C Hamano <gits...@pobox.com> writes: > David Kastrup <d...@gnu.org> writes: > >> Includes reasonably tasteful begging. > > Thanks, but no thanks---I do not see it tasteful.
Well, begging rarely is. The point simply is that without commensurate recompensation, I cannot afford any more work of that kind on Git, and there is a reasonable likelihood that such work is worth more to some subset of Git users than what it would take to enable me doing it. My experience with "tasteful" asking for contributions in the context of AUCTeX and preview-latex development is about €100 plus two cases of beer in 10 years. With GNU LilyPond, I've been way more blunt. Its community certainly is dwarved by the Git community, and still they've been able to support my work with more than €1000 per month for several years now. I've been letting those people down for several months now because of the git-blame stuff, with a respective decline in support to show for that. Sure, partly because of misestimates of the involved work and the involved self-motivation to get it over with. If that's not worth anything to the Git community, I can just chalk it off as a somewhat expensive one-time experience and that's it. I can live with that. What I want to avoid, however, is the situation where this kind of work would actually _have_ been worth enough to enough people to enable it but they don't get to make a decision whether to support more of it and/or express their appreciation in the manner that actually counts, because of being blissfully unaware. Now of course, people having an independent and/or guaranteed can afford to be tasteful. And there are probably enough of those around for running the show. But then "git blame" performance has been sub-par for a very long time already. > In any case, any large change that is not a regression fix (or a fix > to a code added since 1.9 series) is way too late for 2.0 at this > point, For what it's worth, the user interface is unchanged. And results should be the same as previously apart from the runtime requirements. Naturally, this is "should", and problems, particularly regarding different output, may take a long time until somebody notices since few people will actually compare the old and new results. > but I do look forward to reading the patch over, queuing to my tree, > cooking in 'next' and eventually having this in 2.1 or later. > > If you want help in a fundraising campaign, I can lend my name > (especially after this change settles and proves to be useful ;-), In my book, it is a large usability improvement but not necessarily a game changer. Waiting for 1 minute rather than 3 minutes is still nothing one wants enabled in a web server, or that turns stuff into the "interactive response" ballpark. To get that, one will have to work on the remaining performance which is primarily the responsibility of the object store and associated caching. The advantage is that its impact on the performance is now readily visible: previous to this patch it is strongly masked by the sub-par performance of the git-blame code itself. > but let's do that elsewhere. If you have a reasonable idea for that. It would be pointless wherever it safely becomes "somebody else's problem" for pretty much everybody. I'm not overly happy with trying to recruit active developers/power users for that kind of thing when they are a) actively investing time and effort themselves b) outnumbered by profiting users 1000:1 but I've not yet found a better approach myself with regard to LilyPond. If you have a better idea for Git... > I do not want to do this in the release notes (e.g., an entry in > git-blame blog can mention it when it touches the blame improvements). Again: it's important to be visible to those people who might care about putting money in, or it's pointless. At any rate, I'm glad that the work is closed for now. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
