git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Manuel Woelker <manuel.woelker@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>,
	Robin Rosenberg <robin.rosenberg@dewire.com>
Cc: git@vger.kernel.org
Subject: [EGIT] Blame functionality update
Date: Thu, 29 Jan 2009 18:35:28 +0100	[thread overview]
Message-ID: <3d045c7e0901290935l3bddac0emcbaee0b4b2c5695f@mail.gmail.com> (raw)

Hi folks,

quick update about the state of blame functionality in my egit branch
at http://github.com/manuel-woelker/egit/tree/blame
Screen shot here: http://docs.google.com/View?docid=df5rvczr_3f46vd2ds

- Diff support: I changed the IDiff as suggested to work on raw bytes
and IntList's. I also yanked the Diff implementation from wicket and
adapted it for use in jgit. The diff stuff now lives in its own
package. I also added some basic tests to see if plugged diff
implementations conform to the required expectations.

- log support: I added an OriginWalk in the new log package that
traces ancestry of a file though history (including renames and
copying). This might also be neat for the history page, which does not
seem to follow renames at the moment (think "log -C -M"). This is just
a rough sketch atm. Copies are disabled right now, cause the
performance is abysmal, and the current implementation tries to trace
the ancestry of empty lines back to the triassic period. So this could
definitely be optimized. The OriginWalk itself uses RevObject (as
suggested) so it should be a little faster. The implementation
currently traces the different strands of ancestry quite naively,
possibly parsing commits multiple times. This could be improved to a
single pass walk, but this makes the algorithm a little less
straight-forward and I haven't gotten around to that.

- As a result of the the OriginWalk mentioned above, the blame
implementation has been refactored slightly, while still keeping the
basic structure.

- I hooked up the blame functionality to the UI which was easier than
anticipated. I am quite pleased with the result (see screen shot
above). The only thing that proved a little tricky was history and
annotation ruler selection listener notifying each other recursively.
For now I stopped the stack overflow by detecting that recursive call.
If anyone got a better solution just give me a shout.

Feedback, comments and criticism are welcome as always.

Cheers
  - Manuel

             reply	other threads:[~2009-01-29 17:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-29 17:35 Manuel Woelker [this message]
2009-01-29 20:56 ` [EGIT] Blame functionality update Robin Rosenberg
2009-01-31  1:26   ` 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=3d045c7e0901290935l3bddac0emcbaee0b4b2c5695f@mail.gmail.com \
    --to=manuel.woelker@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=robin.rosenberg@dewire.com \
    --cc=spearce@spearce.org \
    /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).