"Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes: > On 8/13/07, David Kastrup <dak@xxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
