From: David Kastrup Date: Sun, 12 Aug 2007 22:54:33 GMT Subject: Re: Can I have this, pretty please? Message-ID: <85ir7k5pp2.fsf@lola.goethe.zz> In-Reply-To: <46a038f90708121517s3ce137e6x898e3f7a59d55a2f@mail.gmail.com> "Martin Langhoff" writes: > On 8/13/07, David Kastrup 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