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
> 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
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.
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