Permalink
Commits on Jul 12, 2007
  1. git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}

    From Johannes Sixt <J.Sixt@eudaptics.com>:
    > It seems that MSYS's wish does some quoting for Bourne shells,
    > in particular, escape the first '{' of the "^{tree}" suffix, but
    > then it uses cmd.exe to run "git rev-parse". However, cmd.exe does
    > not remove the backslash, so that the resulting rev expression
    > ends up in git's guts as unrecognizable garbage: rev-parse fails,
    > and git-gui hickups in a way that it must be restarted.
    
    Johannes originally submitted a patch to this section of commit.tcl
    to use `git rev-parse $PARENT:`, but not all versions of Git will
    accept that format.  So I'm just taking the really simple approach
    here of scanning the first line of the commit to grab its tree.
    About the same cost, but works everywhere.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 12, 2007
Commits on Jul 10, 2007
  1. git-gui: Don't linewrap within console windows

    If we get more than 80 characters of text in a single line odds
    are it is output from git-fetch or git-push and its showing a
    lot of detail off to the right edge that is not so important to
    the average user.  We still want to make sure we show everything
    we need, but we can get away with that information being off to
    the side with a horizontal scrollbar.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 9, 2007
  2. git-gui: Correct ls-tree buffering problem in browser

    Our file browser was showing bad output as it did not properly buffer
    a partial record when read from `ls-tree -z`.  This did not show up on
    my Mac OS X system as most trees are small, the pipe buffers generally
    big and `ls-tree -z` was generally fast enough that all data was ready
    before Tcl started to read.  However on my Cygwin system one of my
    production repositories had a large enough tree and packfile that it
    took a couple of pipe buffers for `ls-tree -z` to complete its dump.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 9, 2007
Commits on Jul 9, 2007
  1. git-gui: Skip nicknames when selecting author initials

    Our blame viewer only grabbed the first initial of the git.git
    author string "Simon 'corecode' Schubert".  Here the problem was we
    looked at Simon, pulled the S into the author initials, then saw
    the single quote as the start of the next name and did not like
    this character as it was not an uppercase letter.
    
    We now skip over single quoted nicknames placed within the author
    name field and grab the initials following it.  So the above name
    will get the initials SS, rather than just S.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 9, 2007
Commits on Jul 6, 2007
  1. git-gui: Ensure windows shortcuts always have .bat extension

    Apparently under some setups on Windows Tk is hiding our file
    extension recommendation of ".bat" from the user and that is
    allowing the user to create a shortcut file which has no file
    extension.  Double clicking on such a file in Windows Explorer
    brings up the associate file dialog, as Windows does not know
    what application to launch.
    
    We now append the file extension ".bat" to the filename of the
    shortcut file if it has no extension or if it has one but it is
    not ".bat".
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 5, 2007
  2. git-gui: Include a Push action on the left toolbar

    Pushing changes to a remote system is a very common action for
    many users of git-gui, so much so that in some workflows a user
    is supposed to push immediately after they make a local commit
    so that their change(s) are immediately available for their
    teammates to view and build on top of.
    
    Including the push button right below the commit button on the
    left toolbar indicates that users should probably perform this
    action after they have performed the commit action.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 6, 2007
  3. git-gui: Bind M1-P to push action

    Users often need to be able to push the current branch so that they
    can publish their recent changes to anyone they are collaborating
    with on the project.  Associating a keyboard action with this will
    make it easier for keyboard-oriented users to quickly activate the
    push features.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 6, 2007
  4. git-gui: Don't bind F5/M1-R in all windows

    We actually only want our F5/M1-R keystroke bound in the main window.
    Within a browser/blame/console window pressing these keys should not
    execute the rescan action.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 6, 2007
Commits on Jul 4, 2007
  1. git-gui: Unlock the index when cancelling merge dialog

    Pressing the escape key while in the merge dialog cancels the merge
    and correctly unlocks the index.  Unfortunately this is not true of
    the Cancel button, using it closes the dialog but does not release
    the index lock, rendering git-gui frozen until you restart it.  We
    now properly release the index lock when the Cancel button is used.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jul 4, 2007
Commits on Jun 30, 2007
  1. git-gui: properly popup error if gitk should be started but is not in…

    …stalled
    
    On 'Visualize ...', a gitk process is started.  Since it is run in the
    background, catching a possible startup error doesn't work, and the error
    output goes to the console git-gui is started from.  The most probable
    startup error is that gitk is not installed; so before trying to start,
    check for the existence of the gitk program, and popup an error message
    unless it's found.
    
    This was noticed and reported by Paul Wise through
     http://bugs.debian.org/429810
    
    Signed-off-by: Gerrit Pape <pape@smarden.org>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Gerrit Pape committed with spearce Jun 29, 2007
Commits on Jun 27, 2007
  1. git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack

    The Tools/Migrate menu option is a hack just for me.  Yes, that's
    right, git-gui has a hidden feature that really only works for me,
    and the users that I support within my day-job's great firewall.
    The menu option is not supported outside of that environment.
    
    In the past we only enabled Tools/Migrate if our special local
    script 'gui-miga' existed in the proper location, and if there
    was a special '.pvcsrc' in the top level of the working directory.
    This latter test for the '.pvcsrc' file is now failing, as the file
    was removed from all Git repositories due to changes made to other
    tooling within the great firewall's realm.
    
    I have changed the test to only work on Cygwin, and only if the
    special 'gui-miga' is present.  This works around the configuration
    changes made recently within the great firewall's realm, but really
    this entire Tools/Migrate thing should be abstracted out into some
    sort of plugin system so other users can extend git-gui as they need.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 26, 2007
  2. git-gui: Don't nice git blame on MSYS as nice is not supported

    Johannes Sixt reported that MinGW/MSYS does not have a nice.exe to
    drop the priority of a child process when it gets spawned.  So we
    have to avoid trying to start `git blame` through nice when we are
    on Windows and do not have Cygwin available to us.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 27, 2007
Commits on Jun 22, 2007
  1. git-gui: Don't require $DISPLAY just to get --version

    Junio asked that we don't force the user to have a valid X11 server
    configured in $DISPLAY just to obtain the output of `git gui version`.
    This makes sense, the user may be an automated tool that is running
    without an X server available to it, such as a build script or other
    sort of package management system.  Or it might just be a user working
    in a non-GUI environment and wondering "what version of git-gui do I
    have installed?".
    
    Tcl has a lot of warts, but one of its better ones is that a comment
    can be continued to the next line by escaping the LF that would have
    ended the comment using a backslash-LF sequence.  In the past we have
    used this trick to escape away the 'exec wish' that is actually a Bourne
    shell script and keep Tcl from executing it.
    
    I'm using that feature here to comment out the Bourne shell script and
    hide it from the Tcl engine.  Except now our Bourne shell script is a
    few lines long and checks to see if it should print the version, or not.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 22, 2007
Commits on Jun 21, 2007
  1. git-gui: Bind Tab/Shift-Tab to cycle between panes in blame

    The blame viewer is composed of two different areas, the file
    area on top and the commit area on the bottom.  If users are
    trying to shift the focus it is probably because they want to
    shift from one area to the other, so we just setup Tab and
    Shift-Tab to jump from the one half to the other in a cycle.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 12, 2007
  2. git-gui: Correctly install to /usr/bin on Cygwin

    Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin
    to /usr/bin can cause problems with the automatic guessing of our
    library location.  The problem is that installation to /usr/bin
    means we actually have:
    
      /usr/bin   = c:\cygwin\bin
      /usr/share = c:\cygwin\usr\share
    
    So git-gui guesses that its library should be found within the
    c:\cygwin\share directory, as that is where it should be relative
    to the script itself in c:\cygwin\bin.
    
    In my first version of this patch I tried to use `cygpath` to resolve
    /usr/bin and /usr/share to test that they were in the same relative
    locations, but that didn't work out correctly as we were actually
    testing /usr/share against itself, so it always was equal, and we
    always used relative paths.  So my original solution was quite wrong.
    
    Mark suggested we just always disable relative behavior on Cygwin,
    because of the complexity of the mount mapping problem, so that's
    all I'm doing.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 19, 2007
Commits on Jun 12, 2007
  1. git-gui: Save geometry before the window layout is damaged

    Because Tk does not assure us the order that it will process
    children in before it destroys the main toplevel we cannot safely
    save our geometry data during a "bind . <Destroy>" event binding.
    The geometry may have already changed as a result of a one or
    more children being removed from the layout.  This was pointed
    out in gitk by Mark Levedahl, and patched over there by commit
    b6047c5.
    
    So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when
    the window is closed by the user, and forward that close event to
    our main do_quit routine.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 12, 2007
Commits on Jun 11, 2007
  1. git-gui: Give amend precedence to HEAD over MERGE_MSG

    Apparently git-commit.sh (the command line commit user interface in
    core Git) always gives precedence to the prior commit's message if
    `commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists.
    
    We actually were doing the same here in git-gui, but the amended
    message got lost if $GIT_DIR/MERGE_MSG already existed because
    we started a rescan immediately after loading the prior commit's
    body into the edit buffer.  When that happened the rescan found
    MERGE_MSG existed and replaced the commit message buffer with the
    contents of that file.  This meant the user never saw us pick up
    the commit message of the prior commit we are about to replace.
    
    Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by
    running `git cherry-pick -n $someid` and then trying to amend the
    prior commit in git-gui, thus combining the contents of $someid
    with the contents of HEAD, and reusing the commit message of HEAD,
    not $someid.  With the recent changes to make cherry-pick use the
    $GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message
    of $someid, not HEAD.  Now we always use HEAD if we are amending.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 11, 2007
  2. git-gui: Include 'war on whitespace' fixes from git.git

    Earlier git.git applied a large "war on whitespace" patch that was
    created using 'apply --whitespace=strip'.  Unfortunately a few of
    git-gui's own files got caught in the mix and were also cleaned up.
    That was a6080a0.
    
    This patch is needed in git-gui.git to reapply those exact same
    changes here, otherwise our version generator script is unable to
    obtain our version number from git-describe when we are hosted in
    the git.git repository.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 11, 2007
Commits on Jun 8, 2007
  1. git-gui: Changed blame header bar background to match main window

    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 <spearce@spearce.org>
    spearce committed Jun 8, 2007
Commits on Jun 6, 2007
  1. git-gui: Favor the original annotations over the recent ones

    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 <spearce@spearce.org>
    spearce committed Jun 6, 2007
  2. git-gui: Improve our labeling of blame annotation types

    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 <spearce@spearce.org>
    spearce committed Jun 6, 2007
  3. git-gui: Use three colors for the blame viewer background

    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 <spearce@spearce.org>
    spearce committed Jun 6, 2007
  4. git-gui: Jump to original line in blame viewer

    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 <spearce@spearce.org>
    spearce committed Jun 4, 2007
  5. git-gui: Display both commits in our tooltips

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  6. git-gui: Run blame twice on the same file and display both outputs

    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 git-gui.sh.  The first pass shows when I created that file, while
    the second pass shows the original commit information.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 2, 2007
  7. git-gui: Display the "Loading annotation..." message in italic

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  8. git-gui: Rename fields in blame viewer to better descriptions

    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 <spearce@spearce.org>
    spearce committed Jun 3, 2007
  9. git-gui: Label the uncommitted blame history entry

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  10. git-gui: Switch internal blame structure to Tcl lists

    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
    arrays.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 2, 2007
  11. git-gui: Cleanup redundant column management in blame viewer

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  12. git-gui: Better document our blame variables

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  13. git-gui: Remove unused commit_list from blame viewer

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  14. git-gui: Automatically expand the line number column as needed

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  15. git-gui: Make the line number column slightly wider in blame

    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 <spearce@spearce.org>
    spearce committed Jun 2, 2007
  16. git-gui: Use lighter colors in blame view

    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
    colors.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Jun 2, 2007