Commits on Jun 8, 2007
  1. git-gui: Changed blame header bar background to match main window

    spearce committed Jun 8, 2007
    The main window's diff header bar background switched from orange
    to gold recently, and I liked the effect it had on readability of
    the text.  Since I wanted the blame viewer to match, here it is.
    Though this probably should be a user defined color, or at least
    a constant somewhere that everyone can reference.
    Signed-off-by: Shawn O. Pearce <>
Commits on Jun 6, 2007
  1. git-gui: Favor the original annotations over the recent ones

    spearce committed Jun 6, 2007
    Usually when you are looking at blame annotations for a region of
    a file you are more interested in why something was originally
    done then why it is here now.  This is because most of the time
    when we get original annotation data we are looking at a simple
    refactoring performed to better organize code, not to change its
    semantic meaning or function.  Reorganizations are sometimes of
    interest, but not usually.
    We now show the original commit data first in the tooltip.  This
    actually looks quite nice as the original commit will usually have an
    author date prior to the current (aka move/copy) annotation's commit,
    so the two commits will now tend to appear in chronological order.
    I also found myself to always be clicking on the line of interest
    in the file column but I always wanted the original tracking data
    and not the move/copy data.  So I changed our default commit from
    $asim_data (the simple move/copy annotation) to the more complex
    $amov_data (the -M -C -C original annotation).
    Signed-off-by: Shawn O. Pearce <>
  2. git-gui: Improve our labeling of blame annotation types

    spearce committed Jun 6, 2007
    It feels wrong to call the -M -C -C annotations "move/copy tracking"
    as they are actually the original locations.  So I'm relabeling
    the status bar to show "copy/move tracking annotations" for the
    current file (no -M -C -C) as that set of annotations tells us who
    put the hunk here (who moved/copied it).  I'm now calling the -M
    -C -C pass "original location annotations" as that's what we're
    really digging for.
    I also tried to clarify some of the text in the hover tooltip.
    Signed-off-by: Shawn O. Pearce <>
  3. git-gui: Use three colors for the blame viewer background

    spearce committed Jun 6, 2007
    To prevent neighboring lines that are different commits from using
    the same background color we now use 3 colors and assign them
    by selecting the color that is not used before or after the line
    in question.  We still color "on the fly" as we receive hunks from
    git-blame, but we delay our color decisions until we are getting
    the original location data (the slower -M -C -C pass) as that is
    usually more fine-grained than the current location data.
    Credit goes to Martin Waitz for the tri-coloring concept.
    Signed-off-by: Shawn O. Pearce <>
  4. git-gui: Jump to original line in blame viewer

    spearce committed Jun 4, 2007
    When the user clicks on a commit link within one of the columns
    in the blame viewer we now jump them not just to that commit/file
    pair but also to the line of the original file.  This saves the
    user a lot of time, as they don't need to search through the new
    file data for the chunk they were previously looking at.
    We also restore the prior view when the user clicks the back button
    to return to a pior commit/file pair that they were looking at.
    Turned out this was quite tricky to get working in Tk.  Every time
    I tried to jump the text widgets to the correct locations by way
    of the "yview moveto" or "see" subcommands Tk performed the change
    until the current event finished dispatching, and then reset the
    views back to 0, making the change never take place.  Forcing Tk
    to run the pending events before we jump the UI resolves the issue.
    Signed-off-by: Shawn O. Pearce <>
  5. git-gui: Display both commits in our tooltips

    spearce committed Jun 2, 2007
    If we have commit data from both the simple blame and the
    rename/move tracking blame and they differ than there is a
    bigger story to tell.  We now include data from both commits
    so that the user can see that this link as moved, who moved
    it, and where it originated from.
    Signed-off-by: Shawn O. Pearce <>
  6. git-gui: Run blame twice on the same file and display both outputs

    spearce committed Jun 2, 2007
    We now perform two passes over any input file given to the blame
    viewer.  Our first pass is a quick "git-blame" with no options,
    getting the details of how each line arrived into this file.  We
    are specifically ignoring/omitting the rename detection logic as
    this first pass is to determine why things got into the state they
    are in.
    Once the first pass is complete and is displayed in the UI we run
    a second pass, using the much more CPU intensive "-M -C -C" options
    to perform extensive rename/movement detection.  The output of this
    second pass is shown in a different column, allowing the user to see
    for any given line how it got to be, and if it came from somewhere
    else, where that is.
    This is actually very instructive when run on our own lib/branch.tcl
    script.  That file grew recently out of a very large block of code
    in  The first pass shows when I created that file, while
    the second pass shows the original commit information.
    Signed-off-by: Shawn O. Pearce <>
  7. git-gui: Display the "Loading annotation..." message in italic

    spearce committed Jun 2, 2007
    If the user clicks on a line region that we haven't yet received
    an annotation for from git-blame we show them "Loading annotation".
    But I don't want the user to confuse this loading message with a
    commit whose first line is "Loading annotation" and think we messed
    up our display somehow.  Since we never use italics for anything
    else, I'm going with the idea that italic slant can be used to show
    data is missing/elided out at the time being.
    Signed-off-by: Shawn O. Pearce <>
  8. git-gui: Rename fields in blame viewer to better descriptions

    spearce committed Jun 3, 2007
    Calling the commit message pane $w_cmit is a tad confusing when
    we also have the $w_cgrp column that shows the abbreviated SHA-1s.
    So w_cmit -> w_cviewer, as it is the "commit viewer"; and
    w_cgrp -> w_amov as it is the "annotated commit + move tracking"
    column.  Also changed line_data -> amov_data, as that list is
    exactly the results shown in w_amov.
    Why call the column "move tracking"?  Because this column holds
    data from "git blame -M -C".  I'm considering adding an additional
    column that holds the data from "git blame" without -M/-C, showing
    who did the copy/move, and when they did it.
    Signed-off-by: Shawn O. Pearce <>
  9. git-gui: Label the uncommitted blame history entry

    spearce committed Jun 2, 2007
    If the user runs the blame viewer on a working directory file
    instead of a specific commit-ish then we have no value for the
    commit SHA1 or the summary line; this causes the history menu
    to get an empty entry at the very bottom.  We now look for this
    odd case and call the meny entry "Working Directory".
    Signed-off-by: Shawn O. Pearce <>
  10. git-gui: Switch internal blame structure to Tcl lists

    spearce committed Jun 2, 2007
    The Tcl list datatype is significantly faster to work with than
    the array type, especially if our indexes are a consecutive set
    of numbers, like say line numbers in a file.
    This rather large change reorganizes the internal data structure
    of the blame viewer to use a proper Tcl list for the annotation
    information about a line.  Each line is given its own list within
    the larger line_data list, where the indexes correspond to various
    facts about that particular line.
    The interface does seem to be more responsive this way, with less
    time required by Tcl to process blame, and to switch to another
    version of the same file.  It could just be a placebo effect, but
    either way most Tcl experts perfer lists for this type of work over
    Signed-off-by: Shawn O. Pearce <>
  11. git-gui: Cleanup redundant column management in blame viewer

    spearce committed Jun 2, 2007
    The code to handle our three different text widgets is a bit
    on the messy side as we issue the same command on all three
    widgets one at a time.  Adding (or removing) columns from the
    viewer is messy, as a lot of locations need to have the new
    column added into the sequence, or removed from it.
    We also now delete the tags we create for each commit when
    we switch to display another "commit:path" pair.  This way the
    text viewer doesn't get bogged down with a massive number of tags
    as we traverse through history.
    Signed-off-by: Shawn O. Pearce <>
  12. git-gui: Better document our blame variables

    spearce committed Jun 2, 2007
    The array variable "order" used to be used to tell us in what
    order each commit was received in.  Recent changes have removed
    that need for an ordering and the "order" array is now just a
    boolean 'do we have that commit yet' flag.
    The colors were moved to fields, so they appear inside of the
    blame viewer instance.  This keeps two different concurrently
    running blame viewers from stepping on each other's ordering
    of the colors in group_colors.
    Most of the other fields were moved around a little bit so
    that they are organized by major category and value lifespan.
    Signed-off-by: Shawn O. Pearce <>
  13. git-gui: Remove unused commit_list from blame viewer

    spearce committed Jun 2, 2007
    This list used to store the commits in the order we received
    them in.  I originally was using it to update the colors of
    the commit before and the commit after the current commit,
    but since that interface concept turned out to be horribly
    ugly and has been removed we no longer need this list.
    Signed-off-by: Shawn O. Pearce <>
  14. git-gui: Automatically expand the line number column as needed

    spearce committed Jun 2, 2007
    After we finish reading a chunk of data from the file stream
    we know how many digits we need in the line number column to
    show the current maximum line number.  If our line number column
    isn't wide enough, we should expand it out to the correct width.
    Any file over our default allowance of 5 digits (99,999 lines)
    is so large that the slight UI "glitch" when we widen the column
    out is trivial compared to the time it will take Git to fully do
    the annotations.
    Signed-off-by: Shawn O. Pearce <>
  15. git-gui: Make the line number column slightly wider in blame

    spearce committed Jun 2, 2007
    Most source code files are under 9,999 lines of text, so using a
    field width of 5 characters meant that we should have had one char
    padding on the left edge (because we right-justify the line number).
    Unfortunately when I added the right margin earlier (when I removed
    the padding) I ate into the extra character's space, losing the left
    margin.  This put the line numbers too close to the commit column in
    any file with more than 999 lines in it.
    Signed-off-by: Shawn O. Pearce <>
  16. git-gui: Use lighter colors in blame view

    spearce committed Jun 2, 2007
    The colors I originally picked out on a Mac OS X system look a
    tad too dark on a Windows 2000 system; the greys are dark enough
    to make it difficult to read some lines of text and the green used
    to highlight the current commit was also difficult to read text on.
    I also added a third grey to the mix, to try and help some files
    that wind up with a number of neighboring chunks getting the same
    Signed-off-by: Shawn O. Pearce <>
  17. git-gui: Remove unnecessary space between columns in blame viewer

    spearce committed Jun 2, 2007
    On Mac OS X the OS has "features" that like to draw thick black
    borders around the text field that has focus.  This is nice if
    you want to know where your text is going and are blind as a bat,
    but it isn't the best thing to have in a table that is being
    faked through the abuse of Tk text widgets.
    By setting our takefocus, highlightthickness and padx/y we can
    get rid of this border and get our text widgets packed right next
    to each other, with no padding between them.  This makes the blame
    background color smoothly run across the entire line of commit data,
    line number and file content.
    Signed-off-by: Shawn O. Pearce <>
  18. git-gui: Remove the loaded column from the blame viewer

    spearce committed Jun 2, 2007
    Originally I had placed this loaded column between the line number
    and the file line data to help users know if a particular line has
    received annotation data or not yet.  This way users would know if
    the line(s) they were interested in were ready for viewing, or if
    they still had to wait.  It also was an entertaining way for the
    user to spend their time waiting for git-blame --incremental to
    compute the complete set of annotations.
    However it is completely useless now that we show the abbreviated
    commit SHA-1 and author initials in the leftmost column.  That area
    is empty until we get the annotation data, and as soon as we get it
    in we display something there, indicating to the user that there is
    now blame data ready.  Further with the tooltips the user is likely
    to see the data as soon as it comes in, as they are probably not
    keeping their mouse perfectly still.  So I'm removing the field to
    save screen space for more useful things, like file content.
    Signed-off-by: Shawn O. Pearce <>
  19. git-gui: Clip the commit summaries in the blame history menu

    spearce committed Jun 2, 2007
    Some commit lines can get really long when users enter a lot of
    text without linewrapping (for example).  Rather than letting the
    menu get out of control in terms of width we clip the summary to
    the first 50+ characters.
    Signed-off-by: Shawn O. Pearce <>
  20. git-gui: Use a label instead of a button for the back button

    spearce committed Jun 2, 2007
    Apparently Tk on Mac OS X won't draw a button with an image using a
    transparent background.  Instead it draws the button using some sort
    of 3D effect, even though I asked for no relief and no border.  The
    background is also not our orange that we expected it to be.
    Earlier I had tried this same trick on Windows and it draws the same
    way as the button did, so I'm going to switch to the label as that
    seems to be more portable.
    Signed-off-by: Shawn O. Pearce <>
  21. git-gui: Show original filename in blame tooltip

    spearce committed Jun 2, 2007
    If we have two commits right next to each other in the final
    file and they were kept as different blocks in the leftmost
    column then its probably because the original filename was
    different.  To help the user know where they are digging into
    when they click on that link we now show the original file in
    the tooltip, but to save space we do so only if the original
    file is not the same as the file we are currently viewing.
    Signed-off-by: Shawn O. Pearce <>
  22. git-gui: Combine blame groups only if commit and filename match

    spearce committed Jun 2, 2007
    Consecutive chunks of a file could come from the same commit, but
    have different original file names.  Previously we would have put
    them into a single group, but then the hyperlink would jump to only
    one of the files, and the other would not be accessible.  Now we can
    get to the other file too.
    Signed-off-by: Shawn O. Pearce <>
  23. git-gui: Allow digging through history in blame viewer

    spearce committed Jun 2, 2007
    gitweb has long had a feature where the user can click on any
    commit the blame display and go visit that commit's information
    page.  From the user could go get the blame display for the file
    they are tracking, and try to digg through the history of any
    part of the code they are interested in seeing.
    We now offer somewhat similiar functionality in git-gui.  The 4
    digit commit abreviation in the first column of our blame view is
    now offered as a hyperlink if the commit isn't the one we are now
    viewing the blame output for (as there is no point in linking back
    to yourself).  Clicking on that link will stop the current blame
    engine (if still running), push the new target commit onto the
    history stack, and restart the blame viewer at that commit, using
    the "original file name" as supplied by git-blame for that chunk
    of the output.
    Users can navigate back to a version they had been viewing before
    by way of a back button, which offers the prior commits in a popup
    menu displayed right below the back button.  I'm always showing the
    menu here as the cost of switching between views is very high; you
    don't want to jump to a commit you are not interested in looking at
    During switches we throw away all data except the cached commit data,
    as that is relatively small compared to most source files and their
    annotation marks.  Unfortunately throwing this per-file data away in
    Tcl seems to take some time; I probably should move the line indexed
    arrays to proper lists and use [lindex] rather than the array lookup
    (usually lists are faster).
    We now start the git-blame process using "nice", so that its priority
    will drop hopefully below our own.  If I don't do this the blame engine
    gets a lot of CPU under Windows 2000 and the git-gui user interface is
    almost non-responsive, even though Tcl is just sitting there waiting
    for events.
    Signed-off-by: Shawn O. Pearce <>
  24. git-gui: Display a progress bar during blame annotation gathering

    spearce committed Jun 1, 2007
    Computing the blame records for a large file with a long project
    history can take git a while to run; traditionally we have shown
    a little meter in the status area of our blame viewer that lets
    the user know how many lines have been finished, and how far we
    are through the process.
    Usually such progress indicators are drawn with a little progress
    bar in the window, where the bar shows how much has been completed
    and hides itself when the process is complete.  I'm using a very
    simple hack to do that: draw a canvas with a filled rectangle.
    Of course the time remaining has absolutely no relationship to the
    progress meter.  It could take very little time for git-blame to get
    the first 90% of the file, and then it could take many times that to
    get the remaining 10%.  So the progress meter doesn't really have any
    sort of assurances that it relates to the true progress of the work.
    But in practice on some ugly history it does seem to hold a reasonable
    indicator to the completion status.  Besides, its amusing to watch and
    that keeps the user from realizing git is being somewhat slow.
    Signed-off-by: Shawn O. Pearce <>
  25. git-gui: Allow the user to control the blame/commit split point

    spearce committed Jun 1, 2007
    At one point I tried to present the blame viewer to an audience of
    people on a 640 by 480 pixel LCD projector.  This did not work at
    all as the top area (the file data) was taking up all of the screen
    realestate and the split point was not adjustable by the user.  In
    general locking the user into a specific ratio of display is just
    not user friendly.
    So we now place a split pane control into the middle of our blame
    window, so the user can adjust it to their current needs.  If the
    window increases (or decreases) in height we assign the difference
    to the file data area, as that is generally the area of the window
    that users are trying to see more of when they grow the window.
    Unfortunately there appears to be a bug in the "pack" layout manager
    in Tcl/Tk 8.4.1.  The status bar and the lower commit pane was being
    squashed if the window decreased in height.  I think the pack manager
    was just not decreasing the size of the panedwindow slave properly if
    the main window shrank.  Switching to the "grid" layout manager fixes
    the problem, but is slightly uglier setup code.
    Signed-off-by: Shawn O. Pearce <>
  26. git-gui: Show author initials in blame groups

    spearce committed Jun 1, 2007
    Frequently when I'm looking at blocks of code in the blame
    viewer I want to know who is the culprit, or who I should
    be praising for a job well done.  The tooltips nicely show
    this if I mouse over a block, but it doesn't work to get
    this detail at a glance.
    Since we don't use the leftmost commit column for anything
    after the first line within a commit group I'm now tossing
    the author's initials into that field, right justified.  It
    is quite clearly not a SHA-1 number as we always show the
    SHA-1 in lowercase, while we explicitly select only the
    uppercase characters from an author's name field, and only
    those that are following whitespace.
    I'm using initials here over anything else as they are quite
    commonly unique within small development teams.  The leading
    part of the email address field was out for some of the teams
    I work with, as there the email addresses are all of the form
    "".  That will never fit into the
    4 characters available.
    Signed-off-by: Shawn O. Pearce <>
  27. git-gui: Space the commit group continuation out in blame view

    spearce committed Jun 1, 2007
    The | in the continued lines of the same commit group as not
    easily seen on the left edge; putting a single space in front
    of the pipe makes it slightly more visually appealing to me as
    I can follow the line down through the group to the next commit
    Signed-off-by: Shawn O. Pearce <>
  28. git-gui: Cleanup minor style nit

    spearce committed Jun 1, 2007
    Signed-off-by: Shawn O. Pearce <>
  29. git-gui: Remove unnecessary reshow of blamed commit

    spearce committed Jun 1, 2007
    Because we no longer redraw colors every time we select a particular
    commit there is no need to redraw the screen after we get a new commit
    in from blame --incremental.
    Signed-off-by: Shawn O. Pearce <>
  30. git-gui: Highlight the blame commit header from everything else

    spearce committed Jun 1, 2007
    The selected commit's blame header is now drawn in green, using
    the same background color that is shown in the main file content
    viewer.  The result is a much better looking commit pane, as we
    use bold for header "keys" and proportional width fonts for the
    stuff that doesn't need to be fixed width to maintain its formatting.
    Signed-off-by: Shawn O. Pearce <>
  31. git-gui: Display tooltips in blame viewer

    spearce committed Jun 1, 2007
    When the mouse is over a particular line and we have blame data
    for that line, but its not the active commit, we should show the
    user information about that commit like who the author was and
    what the subject (first line) was.
    Signed-off-by: Shawn O. Pearce <>
  32. git-gui: Use arror cursor in blame viewer file data

    spearce committed Jun 1, 2007
    Since we don't allow the user to select text from the file
    viewer right now I'm disabling the normal text cursor and
    putting in a plain arror instead.  This way users don't
    think they can select and copy text, because they can't.
    Signed-off-by: Shawn O. Pearce <>
  33. git-gui: Simplify consecutive lines that come from the same commit

    spearce committed Jun 1, 2007
    If two consecutive lines in the final file came from the same commit
    then we store a "|" in the first column rather than the commit id,
    for the second and subsequent lines in that block.  This cleans up
    the interface so runs associated with the same commit can be more
    easily seen visually.
    We also now use the abbreviation "work" for the uncommitted stuff in
    your working directory, rather than "0000".  This looks nicer to the
    eyes and explains pretty quickly what is going on.
    There was also a minor bug in the commit abbreviation column for the
    last line of the file.  This is now also fixed.
    Signed-off-by: Shawn O. Pearce <>
  34. git-gui: Improve the coloring in blame viewer

    spearce committed Jun 1, 2007
    The git-gui blame viewer has always been ugly as s**t.  Linus Torvalds
    suggested the coloring scheme I'm using here, which is two different
    shades of grey for the background colors, and black text on a pale green
    background for the currently selected/focused commit.
    The difference is a massive improvement.  The interface no longer will
    cause seizures in people who are prone to that sort of thing.  It no
    longer uses a very offensive hot pink.  The green being current actually
    makes sense.  And not having the background of the other non-current
    lines change when you change the current commit is really a big deal.
    Signed-off-by: Shawn O. Pearce <>