git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).