Permalink
Commits on Feb 21, 2007
  1. git-gui: Don't crash in citool mode on initial commit.

    spearce committed Feb 21, 2007
    Attempting to use `git citool` to create an initial commit caused
    git-gui to crash with a Tcl error as it tried to add the newly
    born branch to the non-existant branch menu.  Moving this code
    to after the normal commit cleanup logic resolves the issue, as
    we only have a branch menu if we are not in singlecommit mode.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  2. git-gui: Remove TODO list.

    spearce committed Feb 21, 2007
    I'm apparently not very good at keeping my own TODO file current.
    I its also somewhat strange to keep the TODO list as part of the
    software branch, as its meta-information that is not directly
    related to the code.  I'm pulling the TODO list from git-gui and
    moving it into a seperate branch.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  3. git-gui: Include browser in our usage message.

    spearce committed Feb 21, 2007
    Now that the 'browser' subcommand can be used to startup the tree
    browser, it should be listed as a possible subcommand option in
    our usage message.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  4. git-gui: Change summary of git-gui.

    spearce committed Feb 19, 2007
    Since git-gui does more than create commits, it is unfair to call
    it "a commit creation tool".  Instead lets just call it a graphical
    user interface.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  5. git-gui: Display all authors of git-gui.

    spearce committed Feb 19, 2007
    Now that git-gui has been released to the public as part of Git 1.5.0
    I am starting to see some work from other people beyond myself and
    Paul.  Consequently the copyright for git-gui is not strictly the
    two of us anymore, and these others deserve to have some credit
    given to them.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  6. git-gui: Use mixed path for docs on Cygwin.

    spearce committed Feb 19, 2007
    The Firefox browser requires that a URL use / to delimit directories.
    This is instead of \, as \ gets escaped by the browser into its hex
    escape code and then relative URLs are incorrectly resolved, Firefox
    no longer sees the directories for what they are.  Since we are
    handing the browser a true URL, we better use the standard / for
    directories.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 18, 2007
  1. git-gui: Correct crash when saving options in blame mode.

    spearce committed Feb 18, 2007
    Martin Waitz noticed that git-gui crashed while saving the user's
    options out if the application was started in blame mode.  This
    was caused by the do_save_config procedure invoking reshow_diff
    incase the number of context lines was modified by the user.
    Because we bypassed main window UI setup to enter blame mode we
    did not set many of the globals which were accessed by reshow_diff,
    and reading unset variables is an error in Tcl.
    
    Aside from moving the globals to be set earlier, I also modified
    reshow_diff to not invoke clear_diff if there is no path currently
    in the diff viewer.  This way reshow_diff does not crash when in
    blame mode due to the $ui_diff command not being defined.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 16, 2007
  1. git-gui: Expose the browser as a subcommand.

    spearce committed Feb 16, 2007
    Some users may find being able to browse around an arbitrary
    branch to be handy, so we now expose our graphical browser
    through `git gui browse <committish>`.
    
    Yes, I'm being somewhat lazy and making the user give us
    the name of the branch to browse.  They can always enter
    HEAD.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 15, 2007
  1. git-gui: Create new branches from a tag.

    Martin Koegler authored and spearce committed Feb 15, 2007
    I'm missing the possibility to base a new branch on a tag.
    The following adds a tag drop down to the new branch dialog.
    
    Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 14, 2007
  1. git-gui: Prefer version file over git-describe.

    spearce committed Feb 14, 2007
    Some distributions are using Git for part of their package
    management system, but unpack Git's own source code for
    delivery from the .tar.gz.  This means that when we walk
    up the directory tree with git-describe to locate a Git
    repository, the repository we find is for the distribution
    and *not* for git-gui.  Consequently any tag we might find
    there is bogus and does not apply to us.
    
    In this case the version file should always exist and be
    readable, as the packager is working from the released
    .tar.gz sources.  So we should always favor the version
    file over anything git-describe guess for us.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  2. git-gui: Print version on the console.

    spearce committed Feb 14, 2007
    Like `git version`, `git gui version` (or `git gui --version`) shows
    the version of git-gui, in case the user needs to know this, without
    looking at it in the GUI about dialog.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  3. git-gui: More consistently display the application name.

    spearce committed Feb 14, 2007
    I started to find it confusing that git-gui would refer to itself
    as git-citool when it was started through the citool hardlink, or
    with the citool subcommand.  What was especially confusing was the
    options dialog and the about dialog, as both seemed to imply they
    were somehow different from the git-gui versions.  In actuality
    there is no difference at all.
    
    Now we just call our options menu item 'Options...' (skipping the
    application name) and our About dialog now always shows git-gui
    within the short description (above the copyleft notice) and in
    the version field.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  4. git-gui: Permit merging tags into the current branch.

    spearce committed Feb 14, 2007
    It was pointed out on the git mailing list by Martin Koegler that
    we did not show tags as possible things to merge into the current
    branch.  They actually are, and core Git's Grand Unified Merge
    Driver will accept them just like any other commit.
    
    So our merge dialog now requests all refs/heads, refs/remotes and
    refs/tags named refs and attempts to match them against the commits
    not in HEAD.  One complicating factor here is that we must use the
    %(*objectname) field when talking about an annotated tag, as they
    will not appear in the output of rev-list.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  5. git-gui: Basic version check to ensure git 1.5.0 or later is used.

    spearce committed Feb 14, 2007
    This is a very crude (but hopefully effective) check against the
    `git` executable found in our PATH.  Some of the subcommands and
    options that git-gui requires to be present to operate were created
    during the 1.5.0 development cycle, so 1.5 is the minimum version
    of git that we can expect to support.
    
    There actually are early releases of 1.5 (e.g. 1.5.0-rc0) that
    don't have everything we expect (like `blame --incremental`) but
    these are purely academic at this point.  1.5.0 final was tagged
    and released just a few hours ago.  The release candidates will
    (hopefully) fade into the dark quickly.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  6. git-gui: Refactor 'exec git subcmd' idiom.

    spearce committed Feb 13, 2007
    As we frequently need to execute a Git subcommand and obtain
    its returned output we are making heavy use of [exec git foo]
    to run foo.  As I'm concerned about possibly needing to carry
    environment data through a shell on Cygwin for at least some
    subcommands, I'm migrating all current calls to a new git
    proc.  This actually makes the code look cleaner too, as
    we aren't saying 'exec git' everywhere.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 13, 2007
  1. git-gui: fix typo in GIT-VERSION-GEN, "/dev/null" not "/devnull"

    andyparkins authored and spearce committed Feb 13, 2007
    Signed-off-by: Andy Parkins <andyparkins@gmail.com>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 12, 2007
  1. git-gui: Change base version to 0.6.

    spearce committed Feb 12, 2007
    This is the start of the 0.6 series of git-gui.  I'm calling it 0.6
    (rather than any other value) as I already had a private tag on
    one system based on 0.5, and that tag is quite a bit behind this
    version.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  2. git-gui: Guess our version accurately as a subproject.

    spearce committed Feb 12, 2007
    When we are included as a subproject, such as how git.git carries
    us, we want to retain our own version number and not the version
    number assigned by git.git's own tags.  Consequently we need to
    locate the correct tag which applies to our tree content and
    its commit lineage.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  3. git-gui: Handle gitgui tags in version gen.

    spearce committed Feb 12, 2007
    I've decided to use gitgui-0.5 as the format for tags in the
    git-gui repository.  The prefix of gitgui was chosen here to
    make its namespace different from the namespace used by git
    itself, allowing developers to pull both tag namespaces into
    the same repository.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  4. git-gui: Generate a version file on demand.

    spearce committed Feb 12, 2007
    Because git-gui is being shipped as a subproject of the main
    Git project and will often have a different lifecycle than
    the main Git project, we should ship our own version number
    in the release tarball rather than relying on the main Git
    version file.
    
    Git's master Makefile will invoke our own with the target
    dist-version, asking us to save off our GITGUI_VERSION value
    into our own version file, so that our GIT-VERSION-GEN script
    can recover it at build time.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  5. git-gui: Rename GIT_VERSION to GITGUI_VERSION.

    spearce committed Feb 12, 2007
    Now that the decision has been made to treat git-gui as a
    subproject, rather than merging it directly into git, we
    should use a different substitution for our version value
    to avoid any possible confusion.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  6. git-gui: Allow gitexecdir, INSTALL to be set by the caller.

    spearce committed Feb 12, 2007
    When used as a subproject within git.git our Makefile must honor
    the gitexecdir which git.git's Makefile is passing down to us,
    ensuring that we install our executables into the libexec chosen
    by the end-user or packager.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 11, 2007
  1. git-gui: Stop deleting gitk preferences.

    spearce committed Feb 11, 2007
    Now that git 1.5.0 and later contains a version of gitk that uses
    correct geometry on Windows platforms, even if ~/.gitk exists, we
    should not delete the user's ~/.gitk to work around the bug.  It
    is downright mean to remove a user's preferences for another app.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 9, 2007
  1. git-gui: Focus into blame panels on Mac OS.

    spearce committed Feb 9, 2007
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  2. git-gui: Improve annotated file display.

    spearce committed Feb 9, 2007
    Rather than trying to mark the background color of the line numbers
    to show which lines have annotated data loaded, we now show a ruler
    between the line numbers and the file data.  This ruler is just 1
    character wide and its background color is set to grey to denote
    which lines have annotation ready.  I had to make this change as I
    kept loosing the annotation marker when a line was no longer colored
    as part of the current selection.
    
    We now color the lines blamed on the current commit in yellow, the
    lines in the commit which came after (descendant) in red (hotter,
    less tested) and the lines in the commit before (ancestor) in blue
    (cooler, better tested).
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  3. git-gui: Jump to the first annotation block as soon as its available.

    spearce committed Feb 9, 2007
    To help clue users into the fact that annotation data arrives
    incrementally, and that they should try to locate the region
    they want while the tool is running, we jump to the first line
    of the first annotation if the user has not already clicked on
    a line they are interested in and if the window is still looking
    at the very top of the file.
    
    Since it takes a second (at least on my PowerBook) to even generate
    the first annotation for git-gui.sh, the user should have plenty of
    time to adjust the scrollbar or click on a line even before we get
    that first annotation record in, which allows the user to bypass
    our automatic jumping.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  4. git-gui: Redesign the display of annotated files.

    spearce committed Feb 9, 2007
    Using 180 columns worth of screen space to display just 20 columns of
    file data and 160 columns worth of annotation information is not
    practically useful.  Users need/want to see the file data, and have
    the anotation associated with it displayed in a detail pane only when
    they have focused on a particular region of the file.
    
    Now our file viewer has a small 10-line high pane below the file
    which shows the commit message for the commit this line was blamed
    on.  The columns have all been removed, except the current line
    number column as that has some real value when trying to locate an
    interesting block.
    
    To keep the user entertained we have a progress meter in the status
    bar of the viewer which lets them know how many lines have been
    annotated, and how much has been completed.  We use a grey background
    on the line numbers for lines which we have obtained annotation from,
    and we color all lines in the current commit with a yellow background,
    so they stand out when scanning through the file.  All other lines
    are kept with a white background, making the yellow really pop.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  5. git-gui: Use git-config now over git-repo-config.

    spearce committed Feb 9, 2007
    Now that core Git has "renamed" git-repo-config to git-config,
    we should do the same.  I don't know how long core Git will
    keep the repo-config command, and since git-gui's userbase
    is so small and almost entirely on some flavor of 1.5.0-rc2
    or later, where the rename has already taken place, it should
    be OK to rename now.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  6. git-gui: Relabel the Add All action.

    spearce committed Feb 9, 2007
    One user that I spoke with recently was confused why the 'Add All'
    button did not add all of his 'Changed But Not Updated' files.
    The particular files in question were new, and thus not known to
    Git.  Since the 'Add All' routine only updates files which are
    already tracked, they were not added automatically.
    
    I suspect that calling this action 'Add Existing' would be less
    confusing, so I'm renaming it.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  7. git-gui: Select subcommands like git does.

    spearce committed Feb 9, 2007
    If we are invoked as `git-foo`, then we should run the `foo` subcommand,
    as the user has made some sort of link from `git-foo` to our actual
    program code.  So we should honor their request.
    
    If we are invoked as `git-gui foo`, the user has not made a link (or
    did, but is not using it right now) so we should execute the `foo`
    subcommand.
    
    We now can start the single commit UI mode via `git-citool` and also
    through `git gui citool`.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  8. git-gui: View blame from the command line.

    spearce committed Feb 9, 2007
    Viewing annotated files is one of those tasks that is relatively
    difficult to do in a simple vt100 terminal emulator.  The user
    really wants to be able to browse through a lot of information,
    and to interact with it by navigating through revisions.
    
    Now users can start our file viewer with annotations by running
    'git gui blame commit path', thereby seeing the contents of the
    given file at the given commit.  Right now I am being lazy by
    not allowing the user to omit the commit name (and have us thus
    assume HEAD).
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits on Feb 8, 2007
  1. git-gui: Optionally save commit buffer on exit.

    spearce committed Feb 8, 2007
    If the commit area does not exist, don't save the commit message to
    a file, or the window geometry.  The reason I'm doing this is I want
    to make the main window entirely optional, such as if the user has
    asked us to show a blame from the command line.  In such cases the
    commit area won't exist and trying to get its text would cause an
    error.
    
    If we are running without the commit message area, we cannot save
    our window geometry either, as the root window '.' won't be a normal
    commit window.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  2. git-gui: Separate transport/branch menus from multicommit.

    spearce committed Feb 8, 2007
    These are now controlled by the transport and branch options, rather
    than the multicommit option.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  3. git-gui: Refactor single_commit to a proc.

    spearce committed Feb 8, 2007
    This is a minor code cleanup to make working with what used to be the
    $single_commit flag easier.  Its also to better handle various UI
    configurations, depending on command line parameters given by the
    user, or perhaps user preferences.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
  4. git-gui: Replace \ with \\ when showing paths.

    spearce committed Feb 8, 2007
    We already replace \n with \\n so that Tk widgets don't start a new
    display line with part of a file path which is just unlucky enough
    to contain an LF.  But then its confusing to read a path whose name
    actually contains \n as literal characters.  Escaping \ to \\ would
    make that case display as \\n, clarifying the output.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>