tokkee.org

git gui 0.7.0

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Paperbag fix blame in subdirectory

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Format author/committer times in ISO format

This is a simple change to match what gitk does when it shows
a commit; we format using ISO dates (yyyy-mm-dd HH:MM:SS).

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Cleanup minor nits in blame code

We can use [list ...] rather than "", especially when we are talking
about values as then they are properly escaped if necessary.  Small
nit, but probably not a huge deal as the only data being inlined here
is Tk paths.

Some of the lines in the parser code were longer than 80 characters
wide, and they actually were all the same value on the end part of
the line.  Rather than keeping the mess copied-and-pasted around we
can set the last argument into a local variable and reuse it many
times.

The commit display code was also rather difficult to read on an 80
character wide terminal, so I'm moving it all into a double quoted
string that is easier to read.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Generate blame on uncommitted working tree file

If the user doesn't give us a revision parameter to our blame
subcommand then we can generate blame against the working tree
file by passing the file path off to blame with the --contents
argument.  In this case we cannot obtain the contents of the
file from the ODB; instead we must obtain the contents by
reading the working directory file as-is.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Smarter command line parsing for browser, blame

The browser subcommand now optionally accepts a single revision
argument; if no revision argument is supplied then we use the
current branch as the tree to browse.  This is very common, so
its a nice option.

Our blame subcommand now tries to perform the same assumptions
as the command line git-blame; both the revision and the file
are optional.  We assume the argument is a filename if the file
exists in the working directory, otherwise we assume the argument
is a revision name.  A -- can be supplied between the two to force
parsing, or before the filename to force it to be a filename.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use prefix if blame is run in a subdirectory

I think it was Andy Parkins who pointed out that git gui blame HEAD f
does not work if f is in a subdirectory and we are currently running
git-gui within that subdirectory.  This is happening because we did
not take the user's prefix into account when we computed the file
path in the repository.

We now assume the prefix as returned by rev-parse --show-prefix is
valid and we use that during the command line blame subcommand when
we apply the parameters.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Convert blame to the "class" way of doing things

Our blame viewer code has historically been a mess simply
because the data for multiple viewers was all crammed into
a single pair of Tcl arrays.  This made the code hard to
read and even harder to maintain.

Now that we have a slightly better way of tracking the data
for our "meta-widgets" we can make use of it here in the
blame viewer to cleanup the code and make it easier to work
with long term.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't attempt to inline array reads in methods

If a variable reference to a field is to an array, and it is
the only reference to that field in that method we cannot make
it an inlined [set foo] call as the regexp was converting the
Tcl code wrong.  We were producing "[set foo](x)" for "$foo(x)",
and that isn't valid Tcl when foo is an array.  So we just punt
if the only occurance has a ( after it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Convert browser, console to "class" format

Now that we have a slightly easier method of working with per-widget
data we should make use of that technique in our browser and console
meta-widgets, as both have a decent amount of information that they
store on a per-widget basis and our current approach of handling
it is difficult to follow.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Define a simple class/method system

As most of the git-gui interface is based upon "meta-widgets"
that need to carry around a good deal of state (e.g. console
windows, browser windows, blame viewer) we have a good deal
of messy code that tries to store this meta-widget state in
global arrays, where keys into the array are formed from a
union of a unique "object instance id" and the field name.

This is a simple class system for Tcl that allows us to
hide much of that mess by making Tcl do what it does best;
process strings to manipulate its own code during startup.

Each object instance is placed into its own namespace.  The
namespace is created when the object instance is created and
the namespace is destroyed when the object instance is removed
from the system.  Within that namespace we place variables for
each field within the class; these variables can themselves be
scalar values or full-blown Tcl arrays.

A simple class might be defined as:

  class map {
    field data
    field size 0

    constructor {} {
      return $this
    }
    method set {name value} {
      set data($name) $value
      incr size
    }
    method size {} {
      return $size
    } ifdeleted { return 0 }
  }

All fields must be declared before any constructors or methods.  This
allows our class to generate a list of the fields so it can properly
alter the definition of the constructor and method bodies prior to
passing them off to Tcl for definition with proc. A field may optionally
be given a default/initial value.  This can only be done for non-array
type fields.

Constructors are given full access to all fields of the class, so they
can initialize the data values.  The default values of fields (if any)
are set before the constructor runs, and the implicit local variable
$this is initialized to the instance identifier.

Methods are given access to fields they actually use in their body.
Every method has an implicit "this" argument inserted as its first
parameter; callers of methods must be sure they supply this value.

Some basic optimization tricks are performed (but not much).  We
try to only upvar (locally bind) fields that are accessed within a
method, but we err on the side of caution and may upvar more than
we need to.  If a variable is accessed only once within a method
and that access is by $foo (read) we avoid the upvar and instead
use [set foo] to obtain the value.  This is slightly faster as Tcl
does not need to lookup the variable twice.

We also offer some small syntatic sugar for interacting with Tk and
the fileevent callback system in Tcl.  If a field (say "foo") is used
as "@foo" we insert instead the true global variable name of that
variable into the body of the constructor or method.  This allows easy
binding to Tk textvariable options, e.g.:

  label $w.title -textvariable @title

Proper namespace callbacks can also be setup with the special cb proc
that is defined in each namespace.  [cb _foo a] will invoke the method
_foo in the current namespace, passing it $this as the first (implied)
parameter and a as the second parameter.  This makes it very simple to
connect an object instance to a -command option for a Tk widget or to
a fileevent readable or writable for a file channel.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow shift-{k,j} to select a range of branches to merge

I found it useful to be able to use j/k (vi-like keys) to move
up and down the list of branches to merge and shift-j/k to do
the selection, much as shift-up/down (arrow keys) would alter
the selection.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  git-gui: Call changes "Staged" and "Unstaged" in file list titles.

git-gui: Call changes "Staged" and "Unstaged" in file list titles.

All menu entries talk about "staging" and "unstaging" changes, but the
titles of the file lists use different wording, which may confuse
newcomers.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use vi-like keys in merge dialog

Since we support vi-like keys for scrolling in other UI contexts
we can easily do so here too.  Tk's handy little `event generate'
makes this a lot easier than I thought it would be.  We may want
to go back and fix some of the other vi-like bindings to redirect
to the arrow and pageup/pagedown keys, rather than running the
view changes directly.

I've bound 'v' to visualize, as this is a somewhat common thing
to want to do in the merge dialog.  Control (or Command) Return
is also bound to start the merge, much as it is bound in the
main window to activate the commit.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Include commit id/subject in merge choices

When merging branches using our local merge feature it can be
handy to know the first few digits of the commit the ref points
at as well as the short description of the branch name.

Unfortunately I'm unable to use three listboxes in a row, as Tcl
freaks out and refuses to let me have a selection in more than
one of them at any given point in time.  So instead we use a
fixed width font in the existing listbox and organize the data
into three columns.  Not nearly as nice looking, but users can
continue to use the listbox's features.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Show all possible branches for merge

Johannes Sixt pointed out that git-gui was randomly selecting
which branch (or tag!) it will show in the merge dialog when
more than one ref points at the same commit.  This can be a
problem for the user if they want to merge a branch, but the
ref that git-gui selected to display was actually a tag that
points at the commit at the tip of that branch.  Since the
user is looking for the branch, and not the tag, its confusing
to not find it, and worse, merging the tag causes git-merge to
generate a different message than if the branch was selected.

While I am in here and am messing around I have changed the
for-each-ref usage to take advantage of its --tcl formatting,
and to fetch the subject line of the commit (or tag) we are
looking at.  This way we could present the subject line in the
UI to the user, given them an even better chance to select
the correct branch.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Move merge support into a namespace

Like the console procs I have moved the code related to merge
support into their own namespace, so that they are isolated
from the rest of the world.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow vi keys to scroll the diff/blame regions

Users who are used to vi and recent versions of gitk may want
to scroll the diff region using vi style keybindings.  Since
these aren't bound to anything else and that widget does not
accept focus for data input, we can easily support that too.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Move console procs into their own namespace

To help modularize git-gui better I'm isolating the code and
variables required to handle our little console windows into
their own namespace.  This way we can say console::new rather
than new_console, and the hidden internal procs to create the
window and read data from our filehandle are off in their own
private little land, where most users don't see them.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor into multiple files to save my sanity

I'm finding it difficult to work with a 6,000+ line Tcl script
and not go insane while looking for a particular block of code.
Since most of the program is organized into different units of
functionality and not all users will need all units immediately
on startup we can improve things by splitting procs out into
multiple files and let auto_load handle things for us.

This should help not only to better organize the source, but
it may also improve startup times for some users as the Tcl
parser does not need to read as much script before it can show
the UI.  In many cases the user can avoid reading at least half
of git-gui now.

Unfortunately we now need a library directory in our runtime
location.  This is currently assumed to be $(sharedir)/git-gui/lib
and its expected that the Makefile invoker will setup some sort of
reasonable sharedir value for us, or let us assume its going to be
$(gitexecdir)/../share.

We now also require a tclsh (in TCL_PATH) to just run the Makefile,
as we use tclsh to generate the tclIndex for our lib directory.  I'm
hoping this is not an unncessary burden on end-users who are building
from source.

I haven't really made any functionality changes here, this is just a
huge migration of code from one file to many smaller files.  All of
the new changes are to setup the library path and install the library
files.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Track our own embedded values and rebuild when they change

Like core-Git we now track the values that we embed into our shell
script wrapper, and we "recompile" that wrapper if they are changed.
This concept was lifted from git.git's Makefile, where a similar
thing was done by Eygene Ryabinkin.  Too bad it wasn't just done
here in git-gui from the beginning, as the git.git Makefile support
for GIT-GUI-VARS was really just because git-gui doesn't do it on
its own.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor to use our git proc more often

Whenever we want to execute a git subcommand from the plumbing
layer (and on rare occasion, the more porcelain-ish layer) we
tend to use our proc wrapper, just to make the code slightly
cleaner at the call sites.  I wasn't doing that in a couple of
places, so this is a simple cleanup to correct that.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use option database defaults to set the font

Rather than passing "-font font_ui" to every widget that we
create we can instead reconfigure the option database for
all widget classes to use our font_ui as the default widget
font.  This way Tk will automatically setup their defaults
for us, and we can reduce the size of the application.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Cleanup common font handling for font_ui

An earlier change tossed these optionMenu font configurations
all over the code, when really we can just rename the proc to
a hidden internal name and provide our own wrapper to install
the font configuration we really want.

We also don't need to set these option database entries in all
of the procedures that open dialogs; instead we should just set
one time, them after we have the font configuration ready for use.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correct line wrapping for too many branch message

Since Tk automatically wraps lines for us in tk_messageBox
widgets we don't need to try to wrap them ourselves.  Its
actually worse that we linewrapped this here in the script,
as not all fonts will render this dialog nicely.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Warn users before making an octopus merge

A coworker who was new to git-gui recently tried to make an octopus
merge when he did not quite mean to.  Unfortunately in his case the
branches had file level conflicts and failed to merge with the octopus
strategy, and he didn't quite know why this happened.  Since most users
really don't want to perform an octopus merge this additional safety
valve in front of the merge process is a good thing.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Include the subject in the status bar after commit

Now that the command line git-commit has made displaying
the subject (first line) of the newly created commit popular
we can easily do the same thing here in git-gui, without the
ugly part of forking off a child process to obtain that first
line.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  git-gui: Allow spaces in path to 'wish'

git-gui: Allow spaces in path to 'wish'

If the path of our wish executable that are running under
contains spaces we need to make sure they are escaped in
a proper Tcl list, otherwise we are unable to start gitk.

Reported by Randal L. Schwartz on #git.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correctly handle UTF-8 encoded commit messages

Uwe Kleine-König discovered git-gui mangled his surname and did
not send the proper UTF-8 byte sequence to git-commit-tree when
his name appeared in the commit message (e.g. Signed-Off-By line).

Turns out this was related to other trouble that I had in the past
with trying to use "fconfigure $fd -encoding $enc" to select the
stream encoding and let Tcl's IO engine do all of the encoding work
for us.  Other parts of git-gui were just always setting the file
channels to "-encoding binary" and then performing the encoding
work themselves using "encoding convertfrom" and "convertto", as
that was the only way I could make UTF-8 filenames work properly.

I found this same bug in the amend code path, and in the blame
display.  So its fixed in all three locations (commit creation,
reloading message for amend, viewing  message in blame).

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Honor TCLTK_PATH if supplied

Mimick what we do for gitk.  Since you do have a source file,
git-gui.sh, which is separate from the target, it should be much
easier in git-gui's Makefile.

Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Revert "Allow wish interpreter to be defined with TCLTK_PATH"

This reverts commit e2a1bc67d321a0c03737179f331c39a52e7049d7.

Junio rightly pointed out this patch doesn't handle the
`make install` target very well:

Junio C Hamano <junkio@cox.net> writes:
> You should never generate new files in the source tree from
> 'install' target.  Otherwise, the usual pattern of "make" as
> yourself and then "make install" as root would not work from a
> "root-to-nobody-squashing" NFS mounted source tree to local
> filesystem.  You should know better than accepting such a patch.

git-gui: Display the directory basename in the title

By showing the basename of the directory very early in the
title bar I can more easily locate a particular git-gui
session when I have 8 open at once and my  Windows taskbar
is overflowing with items.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'er/ui'

* er/ui:
  Always bind the return key to the default button
  Do not break git-gui messages into multiple lines.
  Improve look-and-feel of the git-gui tool.
  Teach git-gui to use the user-defined UI font everywhere.
  Allow wish interpreter to be defined with TCLTK_PATH

git-gui: Brown paper bag fix division by 0 in blame

If we generate a blame status string before we have obtained
any annotation data at all from the input file, or if the input
file is empty, our total_lines will be 0.  This causes a division
by 0 error when we blindly divide by the 0 to compute the total
percentage of lines loaded.  Instead we should report 0% done.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Always bind the return key to the default button

If a dialog/window has a default button registered not every
platform associates the return key with that button, but all
users do.  We have to register the binding of the return key
ourselves to make sure the user's expectations of pressing
return will activate the default button are met.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Do not break git-gui messages into multiple lines.

Many git-gui messages were broken into a multiple lines to make
good paragraph width. Unfortunately in reality it breaks the paragraph
width completely, because the dialog window width does not coincide
with the paragraph width created by the current font.

Tcl/Tk's standard dialog boxes are breaking the long lines
automatically, so it is better to make long lines and let the
interpreter do the job.

Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Improve look-and-feel of the git-gui tool.

Made the default buttons on the dialog active and focused upon the
dialog appearence.

Bound 'Escape' and 'Return' keys to the dialog dismissal where it
was appropriate: mainly for dialogs with only one button and no
editable fields, but on console output dialogs as well.

Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Teach git-gui to use the user-defined UI font everywhere.

Some parts of git-gui were not respecting the default GUI font.
Most of them were catched and fixed.

Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Allow wish interpreter to be defined with TCLTK_PATH

Makefile got one external option:
- TCLTK_PATH: the path to the Tcl/Tk interpreter.

Users (or build wrappers) may set this variable to the
location of the wish executable.

Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  git-gui: Allow 'git gui version' outside of a repository
  git-gui: Revert "git-gui: Display all authors of git-gui."
  git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."
  git-gui: Allow committing empty merges

git-gui: Allow 'git gui version' outside of a repository

I got a little surprise one day when I tried to run 'git gui version'
outside of a Git repository to determine what version of git-gui was
installed on that system.  Turns out we were doing the repository
check long before we got around to command line argument handling.

We now look to see if the only argument we have been given is
'version' or '--version', and if so, print out the version and
exit immediately; long before we consider looking at the Git
version or working directory.  This way users can still get to
the git-gui version number even if Git's version cannot be read.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Revert "git-gui: Display all authors of git-gui."
This reverts commit 871f4c97ad7e021d1a0a98c80c5da77fcf70e4af.

Too many users have complained about the credits generator in
git-gui, so I'm backing the entire thing out.  This revert will
finish that series.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."
This reverts commit 92446aba47b0e0db28f7b858ea387efcca30ab44.

Too many users have complained about the credits generator in
git-gui, so I'm backing the entire thing out.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow committing empty merges

Johannes Sixt noticed that git-gui would not let the user commit
a merge created by `git merge -s ours` as the ours strategy does
not alter the tree (that is HEAD^1^{tree} = HEAD^{tree} after the
merge).  The same issue arises from amending such a merge commit.

We now permit an empty commit (no changed files) if we are doing
a merge commit.  Core Git does this with its command line based
git-commit tool, so it makes sense for the GUI to do the same.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Support of "make -s" in: do not output anything of the build itself

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Make 'make' quieter by default

To fit nicely into the output of the git.git project's own quieter
Makefile, we want to make the git-gui Makefile nice and quiet too.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove unnecessary /dev/null redirection.

Git 1.5.0 and later no longer output useless messages to standard
error when making the initial (or what looks to be) commit of a
repository.  Since /dev/null does not exist on Windows in the
MinGW environment we can't redirect there anyway.  Since Git
does not output anymore, I'm removing the redirection.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't create empty (same tree as parent) commits.

Mark Levedahl noticed that git-gui will let you create an empty
normal (non-merge) commit if the file state in the index is out
of whack.  The case Mark was looking at was with the new autoCRLF
feature in git enabled and is actually somewhat difficult to create.

I found a different way to create an empty commit:  turn on the
Trust File Modifications flag, touch a file, rescan, then move
the file into the "Changes To Be Committed" list without looking
at the file's diff.  This makes git-gui think there are files
staged for commit, yet the update-index call did nothing other
than refresh the stat information for the affected file.  In
this case git-gui allowed the user to make a commit that did
not actually change anything in the repository.

Creating empty commits is usually a pointless operation; rarely
does it record useful information.  More often than not an empty
commit is actually an indication that the user did not properly
update their index prior to commit.  We should help the user out
by detecting this possible mistake and guiding them through it,
rather than blindly recording it.

After we get the new tree name back from write-tree we compare
it to the parent commit's tree; if they are the same string and
this is a normal (non-merge, non-amend) commit then something
fishy is going on.  The user is making an empty commit, but they
most likely don't want to do that.  We now pop an informational
dialog and start a rescan, aborting the commit.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Add Reset to the Branch menu.

cehteh on #git noticed that there was no way to perform a reset --hard
from within git-gui.  When I pointed out this was Merge->Abort Merge
cehteh said this is not very understandable, and that most users would
never guess to try that option unless they were actually in a merge.

So Branch->Reset is now also a way to cause a reset --hard from within
the UI.  Right now the confirmation dialog is the same as the one used
in Merge->Abort Merge.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Relocate the menu/transport menu code.

This code doesn't belong down in the main window UI creation,
its really part of the menu system and probably should be
located with it.  I'm moving it because I could not find
the code when I was looking for it earlier today, as it was
not where I expected it to be found.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Don't modify CREDITS-FILE if it hasn't changed.

We should always avoid rewriting a built file during `make install`
if nothing has changed since `make all`.  This is to help support
the typical installation process of compiling a package as yourself,
then installing it as root.

Forcing CREDITS-FILE to be always be rebuilt in the Makefile means
that CREDITS-GEN needs to check for a change and only update
CREDITS-FILE if the file content actually differs.  After all,
content is king in Git.

Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't crash in citool mode on initial commit.

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>

git-gui: Remove TODO list.

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>

git-gui: Include browser in our usage message.

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>

git-gui: Change summary of git-gui.

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>

git-gui: Display all authors of git-gui.

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>

git-gui: Use mixed path for docs on Cygwin.

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>

git-gui: Correct crash when saving options in blame mode.

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>

git-gui: Expose the browser as a subcommand.

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>

git-gui: Create new branches from a tag.

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>

git-gui: Prefer version file over git-describe.

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>

git-gui: Print version on the console.

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>

git-gui: More consistently display the application name.

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>

git-gui: Permit merging tags into the current branch.

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>

git-gui: Basic version check to ensure git 1.5.0 or later is used.

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>

git-gui: Refactor 'exec git subcmd' idiom.

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>

git-gui: fix typo in GIT-VERSION-GEN, "/dev/null" not "/devnull"

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Change base version to 0.6.

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>

git-gui: Guess our version accurately as a subproject.

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>

git-gui: Handle gitgui tags in version gen.

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>

git-gui: Generate a version file on demand.

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>

git-gui: Rename GIT_VERSION to GITGUI_VERSION.

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>

git-gui: Allow gitexecdir, INSTALL to be set by the caller.

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>

git-gui: Stop deleting gitk preferences.

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>

git-gui: Focus into blame panels on Mac OS.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Improve annotated file display.

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>

git-gui: Jump to the first annotation block as soon as its available.

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>

git-gui: Redesign the display of annotated files.

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>

git-gui: Use git-config now over git-repo-config.

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>

git-gui: Relabel the Add All action.

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>

git-gui: Select subcommands like git does.

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>

git-gui: View blame from the command line.

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>

git-gui: Optionally save commit buffer on exit.

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>

git-gui: Separate transport/branch menus from multicommit.

These are now controlled by the transport and branch options, rather
than the multicommit option.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor single_commit to a proc.

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>

git-gui: Replace \ with \\ when showing paths.

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>

git-gui: Support keyboard traversal in browser.

Users want to navigate the file list shown in our branch browser
windows using the keyboard.  So we now support basic traversal
with the arrow keys:

  Up/Down:  Move the "selection bar" to focus on a different name.

  Return:   Move into the subtree, or open the annotated file.
  M1-Right: Ditto.

  M1-Up:    Move to the parent tree.
  M1-Left:  Ditto.

Probably the only feature missing from this is to key a leading part
of the file name and jump directly to that file (or subtree).

This change did require a bit of refactoring, to pull the navigation
logic out of the mouse click procedure and into more generic routines
which can also be used in bindings.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Update known branches during rescan.

If the user has created (or deleted) a branch through an external tool,
and uses Rescan, they probably are trying to make git-gui update to show
their newly created branch.

So now we load all known heads and update the branch menu during any
rescan operation, just in-case the set of known branches was modified.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Assign background colors to each blame hunk.

To help the user visually see which lines are associated with each other
in the file we attempt to sign a unique background color to each commit
and then render all text associated with that commit using that color.

This works out OK for a file which has very few commits in it; but
most files don't have that property.

What we really need to do is look at what colors are used by our
neighboring commits (if known yet) and pick a color which does not
conflict with our neighbor.  If we have run out of colors then we
should force our neighbor to recolor too.  Yes, its the graph coloring
problem.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use a grid layout for the blame viewer.

Using a panedwindow to display the blame viewer's individual columns
just doesn't make sense.  Most of the important data fits within the
columns we have allocated, and those that don't the leading part fits
and that's good enough.  There are just too many columns within this
viewer to let the user sanely control individual column widths.  This
change shouldn't really be an issue for most git-gui users as their
displays should be large enough to accept this massive dump of data.

We now also have a properly working horizontal scrollbar for the
current file data area.  This makes it easier to get away with a
narrow window when screen space is limited, as you can still scroll
around within the file content.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Install column headers in blame viewer.

I started to get confused about what each column meant in the blame
viewer, and I'm the guy who wrote the code!  So now git-gui hints to
the user about what each column is by drawing headers at the top.
Unfortunately this meant I had to use those dreaded frame objects
which seem to cause so much pain on Windows.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display original filename and line number in blame.

When we annotate a file and show its line data, we're already asking
for copy and movement detection (-M -C).  This costs extra time, but
gives extra data.  Since we are asking for the extra data we really
should show it to the user.

Now the blame UI has two additional columns, one for the original
filename (in the case of a move/copy between files) and one for the
original line number of the current line of code.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correctly handle spaces in filepaths.

Anytime are about to open a pipe on what may be user data we need to
make sure the value is escaped correctly into a Tcl list, so that the
executed subprocess will receive the right arguments.  For the most
part we were already doing this correctly, but a handful of locations
did not.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use -M and -C when running blame.

Since we run blame incrementally in the background we might as well get
as much data as we can from the file.  Adding -M and -C definately makes
it take longer to compute the revision annotations, but since they are
streamed in and updated as they are discovered we'll get recent data
almost immediately anyway.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow users to edit user.name, user.email from options.

Users may need to be able to alter their user.name or user.email
configuration settings.  If they are mostly a git-gui user they
should be able to view/set these important values from within
the git-gui environment, rather than needing to edit a raw text
file on their local filesystem.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display the current branch name in browsers.

Rather than using HEAD for the current branch, use the actual name of
the current branch in the browser.  This way the user knows what a
browser is browsing if they open up different browsers while on different
branches.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Improve the icons used in the browser display.

Real icons which seem to indicate going up to the parent (an up arrow)
and a subdirectory (an open folder).  Files are now drawn with the
file_mod icon, like a modified file is.  This just looks better as it
is more consistent with the rest of our UI.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Implemented file browser and incremental blame.

This rather huge change provides a browser for the current branch.  The
browser simply shows the contents of tree HEAD, and lets the user drill
down through the tree.  The icons used really stink, as I just copied in
icon which we already had.  I really need to replace the file_dir and
file_uplevel icons with something more useful.

If the user double clicks on a file within the browser we open it in
a blame viewer.  This makes use of the new incremental blame feature
that Linus just added yesterday to core Git.  Fortunately the feature
will be in 1.5.0 final so we can rely on having it available here.

Since the blame engine is incremental the user will get blame data
for groups which can be determined early.  Git will slowly fill in
the remaining lines as it goes.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>