Re: Can I have this, pretty please?
- From
Martin Langhoff <martin.langhoff@gmail.com>
- Date
- Aug 12, 2007, 22:17 UTC
- Message-ID
- <46a038f90708121517s3ce137e6x898e3f7a59d55a2f@mail.gmail.com>
- In-Reply-To
- <85y7gg5tc3.fsf@lola.goethe.zz>
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 ;-)
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.
I *thought* there was one -- I was just reading gitk to check and not look like a doofus -- but at least my gitk is exec'ing git cat-file all over the place. I am sure that it'd speed up gitk and friends enormoustly, specially on non-linux environments where IO isn't as optimised.
cheers,
m