From: "Shawn O. Pearce" <spearce@spearce.org>
To: "Roger C. Soares" <rogersoares@intelinet.com.br>
Cc: Robin Rosenberg <robin.rosenberg@dewire.com>, git@vger.kernel.org
Subject: Re: faster egit history page and a pure java "gitk"
Date: Tue, 25 Mar 2008 01:36:49 -0400 [thread overview]
Message-ID: <20080325053649.GE4759@spearce.org> (raw)
In-Reply-To: <47E8889E.6090403@intelinet.com.br>
"Roger C. Soares" <rogersoares@intelinet.com.br> wrote:
> Shawn O. Pearce escreveu:
> >The history page has been completely replaced.
>
> I have a git.git clone on my eclipse and now egit can open it, cool! :)
Yea, that was my impression too. "Yay, it can open git.git!" :)
> But it wasn't that fast, it took some minutes to finish building the
> whole tree. Also, changing projects (different git repos) makes the cpu
> go very high, and what opened fast the first time takes minutes after...
Hmm. How long does C Git take for "git rev-list HEAD >/dev/null" ?
I have thus far only tuned the lower level machinary, and there
may still be tuning left there, but I _really_ have not tried to
tune the plotting portion yet.
I did push something out a few minutes ago (b66eae Limit the number
of UI refreshes ...) that may help improve performance on larger
histories.
Another thing is how many pack files/loose objects do you have?
The loose objects are harder to access, and jgit is currently
lacking some of the pack search tricks that C Git uses to get
good performance. As such all of my testing has been working on
a fully packed repository that has exactly one packfile in it,
with no alternates.
Its _almost_ acceptable to me. We can still do better, but there's
a point at which we just can't get past. We probably can't beat
rev-list, but I think we should be able to beat gitk almost always.
In the simple fully packed case "jgit glog" beats gitk at opening
the full graph and displaying it.
> When reading the email I thought the new history page would have the
> same features from the current, but it doesn't. It looks promissing thought.
Nope. Sorry. Its basically a rewrite.
> My first impression is that I like the current way of showing files in
> the strutucture compare better.
I actually prefer the individual files in the right pane, like gitk
does, as I like to browse up and down sometimes looking at changes.
Maybe we can make it an option to show that right side panel,
and give a button (or IOpenListener on the graph table?) to let
you open the whole commit in the structure compare view.
> In the future I would like the option to
> make it open on the left pane (where package explorer is) and have the
> options to collapse/expand directories, present in flat/hierarchical
> modes, have the fast view, etc.
Oooh. Sounds fun.
> Comments now can't be automatically wrapped.
Oversight/planned loss of feature. I'm a strong believer of showing
the commit message *exactly* as recorded, which means don't do
line wrapping of it. Things like character encoding translation
and indenting the left side 2-4 spaces to keep it unambiguous from
headers is fine when showing it to a human, but otherwise it should
match what the user wrote.
I forgot to offer a wrap option. If we do enable line wrapping I
think we should give the user a way to toggle it on/off for the
message area viewer so that if line wrapping is enabled and its
borking the current message (e.g. a nice pretty ASCII diagram)
you can disable it.
> I actually prefer to leave
> wrapping to the computer, I don't like having to manually fix line
> lenghts when amending a comment, I think eclipse should do it. Also,
> currently, the history page usually has little space allocated for it
> and currently the first lines of the comment are visible. In the new
> page I have to scroll to see the comment when the history page is not
> maximized.
Yea, I started to notice that myself today. The area isn't quite
wide enough, and I was using Eclipse on a very high resolution CRT
and it was taking up a good 80% of the display. Most users can't
sanely devote the area I did to the History view, and it was still
not wide enough for some git.git messages.
Thanks for the feedback. Obviously its still got a lot of areas
for improvements.
--
Shawn.
next prev parent reply other threads:[~2008-03-25 5:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-24 9:27 faster egit history page and a pure java "gitk" Shawn O. Pearce
2008-03-24 13:33 ` Roger C. Soares
2008-03-24 14:10 ` Robin Rosenberg
2008-03-25 4:43 ` Shawn O. Pearce
2008-03-25 12:33 ` Roger C. Soares
2008-03-24 14:06 ` Robin Rosenberg
2008-03-25 5:10 ` Shawn O. Pearce
2008-03-24 14:31 ` faster egit history page and a pure java "gitk" so Robin Rosenberg
2008-03-25 4:48 ` Shawn O. Pearce
2008-03-25 5:07 ` faster egit history page and a pure java "gitk" Roger C. Soares
2008-03-25 5:36 ` Shawn O. Pearce [this message]
2008-03-25 8:09 ` Shawn O. Pearce
2008-03-25 13:46 ` Roger C. Soares
2008-03-25 19:48 ` Robin Rosenberg
2008-03-26 1:37 ` Roger C. Soares
2008-03-26 4:52 ` Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080325053649.GE4759@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg@dewire.com \
--cc=rogersoares@intelinet.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).