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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This reverts commit e2a1bc67d3.
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.
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>
* 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
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>
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>
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>
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>
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>
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>
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>
This reverts commit 871f4c97ad.
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>
This reverts commit 92446aba47.
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>
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>
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 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>
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>
Shawn O. Pearce