Re: Can I have this, pretty please?

[David Kastrup <dak@gnu.org>]

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

> On 8/13/07, David Kastrup <dak@gnu.org> wrote:
>> Well, what I have in mind boils down to something I can use without
>> leaving my editor... (...) and I naturally use Emacs.
>
> heh! As an emacs user, I have to say this might just be a tad too
> much :-)
>
> The main fix for your immediate woes of having gitk work fast is -
> imho - to limit it by time, which I do all the time.
>
> And on that track I'd *love* it if gitk could work as follows:
> start-up as if I had said --since=10.days.ago (unless I pass an
> explicit --since) and put a "get more history" button at the bottom
> of the commit list. And make the default --since settable via git
> config as gitk.since or somesuch.
>
> That'd make newcomers to git go -- WOW -- on gitk, and save old
> hands some typing ;-)

Sigh.  Why does one have to limit _anything_?  gitk can just keep
asking git-rev-list -20 --stdin enough questions to fill the screen.
It can get more history if it _needs_ it.

tig actually sucks up the whole of Emacs history (100000 commits per
branch) as fast as git-rev-list can produce it.  Without locking or
swapping.

> On the gnus backend - I don't think the nntp backend is good enough,
> as it can't deal with merges. But if you can write up a new backend
> that can read merges, you'll be golden. You'll definitely want to
> limit the number of commits you read initially, too.
>
> Now - both your emacs-gnus-git backend and gitk/qgit would benefit
> from having a long-lived git process that you can talk to via a
> socket for the stuff that you are bound to be asking a lot of
> (cat-file, diff, etc). Something like git-fastimport but for common
> queries.

Can be pipes.  Pretty common way of talking to utilities from within
Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum