git-gui: Allow the user to copy the version data to the clipboard.

If a user wants to report an issue they will likely want to include
the version number with their issue report.  This may be difficult
to enter if the version number includes an abbreviated commit SHA1
on the end of it.  So we now give the user a context menu option
on the version box which allows them to copy all of the relevant
version data to the clipboard, ready for pasting into a report.

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

git-gui: Ensure version number is always current.

I'm stealing the exact logic used by core Git within its own Makefile to
setup the version number within scripts and executables.  This way we
can be sure that the version number is always updated after a commit,
and that the version number also reflects when it is coming from a dirty
working directory (and is thus pretty worthless).

I've cleaned up some of the version display code in the about dialog too.
There were simply too many blank lines in the bottom section where we
showed the version data.

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

git-gui: Display the full GPL copyright notice in about dialog.

We're a true GPL program, and we're interactive.  We should show the
entire GPL notice and disclaimer of warranty in our about dialog upon
request by the user, as well as include it in the header of our source.
Perhaps overkill, but is recommended by our license.

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

git-gui: Display the git-gui version in the Help->About dialog.

Now that we know what version git-gui is, the about dialog should
display it to the end-user.  This way users can find out what version
they have before they report a problem or request a feature.

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

git-gui: Modified makefile to embed version into git-gui script.

We want to embed the version of git-gui directly into the script file,
so that we can display it properly in the about dialog.  Consequently
I've refactored the Makefile process to act like the one in core git.git
with regards to shell scripts, allowing git-gui to be constructed by a
sed replacement performed on git-gui.sh.

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

git-gui: Hide the ugly bash command line from the windows desktop icon.

The user really doesn't need to see the technical details of how we
launch git-gui from within their "desktop icon".  Instead we should hide
the command line from being displayed when the icon launches by putting
@ at the start of the line.  If they really need to see the command we
are running they can edit the batch file.

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

git-gui: Change more 'include' language to 'add'.

I just found a whole slew of places where we still were using the term
'include' rather than 'add' to refer to the act of updating the index
with modifications from the working directory.  To be consistent with
all Git documentation and command line tools, these should be 'add'.

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

git-gui: Work around odd cygpath bug on Windows.

There appears to be a bug on one of my test systems where cygpath with
the --long-name option is generating a corrupt string that does not
actually refer to sh.exe.  This breaks any desktop icon created by
git-gui as the executable we are trying to invoke does not exist.
Since Cygwin is typically installed as C:\cygwin long path names is
probably not actually necessary to link to the shell.

I also added a small echo to the start of the icon script, as it can
take one of my test systems several seconds to startup git-gui.  This
way the user knows we're starting git-gui, and was politely asked to
wait for the action to complete.

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

git-gui: Correct wording of the revert confirmation dialog.

We no longer describe updating the index as including changes, as we
now use the add notation used by core Git's command line tools.  So
its confusing to be talking about unincluded changes within the revert
dialog.  Instead we should used language like 'unadded changes'.

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

git-gui: Corrected behavior of deleted (but existing in HEAD) files.

Apparently I did not account for the D_ file state.  This can occur when
a file has been marked for deletion by deleting it from the index, and
the file also does not exist in the working directory.  Typically this
happens when the user deletes the file, hits Rescan, then includes the
missing file in the commit, then hits Rescan again.  We don't find the
file in the working directory but its been removed in the index, so the
state becomes D_.

This state should be identical with DD.  I'm not entirely sure why DD
occurs sometimes and D_ others, it would seem like D_ is the state that
should be happening instead of DD, leading me to believe there is a quirk
in git-gui's state manipulation code.

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

git-gui: Run git-gc rather than git-repack.

Now that git 1.5.0-rc1 and later has a 'git gc' command which performs
all important repository management activites (including reflog pruning,
repacking local objects, unnecessary loose object pruning and rerere cache
expiration) we should run 'gc' when the user wants us to cleanup their
object database for them.

I think the name 'gc' is horrible for a GUI application like git-gui,
so I'm labeling the menu action 'Compress Database' instead.  Hopefully
this will provide some clue to the user about what the action does.

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

git-gui: Show all fetched branches for remote pulls.

Loop through every remote.<name>.fetch entry and add it as a valid
option in the Pull menu.  This way users can pull any remote branch
that they track, without needing to leave the gui.  Its a rather crude
work around for not having a full merge interface.

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

git-gui: Created very crude Tools menu, to support miga.

In one particular case I have a tool called 'miga' which users may need
to invoke on their repository.  This is a homegrown tool which is not
(and should be) part of git-gui, but I still want to be able to run it
from within the gui.

Right now I'm taking a shortcut and adding it to the Tools menu if
we are not on Mac OS X and the support script used to launch the tool
exists in the local filesystem.  This is nothing but a complete and
utter hack.

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

git-gui: Reworded 'Include' to 'Add' to match core Git.

Now that git-add is a first class citizen in core Git (Nico's 366bfcb6)
users may start to expect the term 'add' to refer to the act of including
a file's changes into a commit.  So I'm replacing all uses of the term
'Include' in the UI with 'Add'.

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

git-gui: Auto-update any A? or M? files during rescan.

If the user has partial includes disabled then it doesn't matter what
state the working directory is in; if the file has been included in
the next commit its index state is A or M and we should immediately
run update-index on the working directory file to bring the index in
sync with the working directory.

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

git-gui: Enable resolution of merge conflicts.

If a file has a merge conflict (index state = U) the user will need to
run update-index on that file to resolve all stages down to stage 0,
by including the file in the working directory.

Like core Git we'll just trust the user that their resolution is
correct, and that they didn't just include the file into the commit
while merge conflicts still exist within the file.

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

git-gui: Updated todo list.

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

git-gui: Set a proper title on our revert confirm dialog box.

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

git-gui: Started implementation of switch_branch.

This implementation of switch_branch is not yet finished, and thus
it throws a "NOT FINISHED" error rather than completing the switch.
But its a rough sketch of the procedure required.

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

git-gui: Misc. comment and formatting cleanups.

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

git-gui: Rename all_branches -> all_heads.

Since this list is really the set of refs which match "refs/heads/*" it
really is the set of heads and not necessarily the set of all branches,
as the remote tracking branches are not listed in this set, even if it
appears in the "refs/heads/*" namespace (e.g. an old style repository).

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

git-gui: Automatically skip tracking branches in branch menu.

Since the user should not work on a tracking branch we automatically
hide any branch which is used as a tracking branch by either a
remote.<name>.fetch config entry or by a Pull: line in a remotes file.

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

git-gui: Abort on not implemented branch switching.

I'm not currently ready to implement branch switching, so I'm just
going to punt on it for now.  :-)

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

git-gui: Parse off refs/remotes when showing current branch.

Even though the user shouldn't have a remote branch checked out, if
they do we should still show as short of the branch name as possible.

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

git-gui: Created Branch menu.

This is an early start at branch management from within git-gui.  The
branch menu has create/delete command entries to create and delete
branches as well as a list of radiobutton entries for each branch
found in the repository through for-each-ref.

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

git-gui: Support file state MD (modified/deleted).

Apparently I missed the file state MD, which is a file modified and
updated in the index but then removed from the working directory.  This
should be treated just like AD, an added file which has been deleted from
the working directory.

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

git-gui: Display the current branch.

Users want to know what branch they are sitting on before making a commit,
as they may need to switch to a different branch first.

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

git-gui: Added revert changes command.

Users sometimes need to be able to throw away locally modified files
in order to go back to the last committed version of that file.  To
perform a revert the user must first uninclude each file from the new
commit as the working file must at least partially match the index,
and we use git-checkout-index to update the working directory.

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

git-gui: Improve pull error dialogs.

Just like prior to a commit its only an informational message that
we refuse to perform a pull on a dirty working directory.  Therefore
we should not use an error icon.

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

git-gui: Don't start 'gitk --all' on Mac OS X.

Since gitk is currently broken on Mac OS X and is unable to start itself
when given command line parameters just don't offer the "Visual All
Branches" menu option on Mac OS X.

Once this feature of gitk is fixed we should change this section of code
to make sure a working version of gitk will be executed before we offer
the option up to the user.

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

git-gui: Added menu command to visualize all branches.

Sometimes its useful to start gitk with the --all option, to view all of
the known branches and tags within this repository.  Rather than making
the user startup gitk and then edit the view we can pass the option along
for them.

This also makes it slightly more explicit, that when gitk starts up by
default its showing the current branch and not everything.  Yes gitk
isn't showing that to the user, but the fact that the user had to make
a decision between seeing this current branch or all branches will
hopefully make them study gitk's display before jumping to a conclusion.

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

git-gui: Refactor M1 binding selection.

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

git-gui: Added configuration editor TODO list.

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

git-gui: Warn Cygwin users about possible environment issues.

Because the Tcl binary distributed with Cygwin tends to not pass along
its own environment (the env array) to its children, its unlikely that
any Git commands spawned by git-gui will receive the same environment
variables that git-gui itself received from the shell which started it.

If the user is counting on environment variables to pass down, like say
GIT_INDEX_FILE, they may not, so we warn them during git-gui startup
that things may not work out as the user intended.  Perhaps one day
when git-gui and git are running on native Windows (rather than through
the Cygwin emulation layers) things will work better.

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

git-gui: Correct is_MacOSX platform test.

Darwn based UNIX systems are not necessarily Mac OS X.  However the only
windowing system used by Tk that is Mac OS X is 'aqua', and only 'aqua'
exists on Mac OS X.  Therefore this is a more reliable test for the
Macintosh platform.

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

git-gui: Abstract out windows platform test to is_Windows proc.

Like the is_MacOSX proc we shouldn't keep repeating the platform test
for Windows.  Instead abstract the code out into a procedure and use
the procedure whenever we need to do something special.

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

git-gui: Include the Tcl/Tk version in the about dialog.

Users may need to know what version of Tcl they are running git-gui
under, in case there is an interesting interface quirk or other
compatability problem we don't know about right now that we may
need to explore (and maybe fix).  Since its simple enough to show
a line with this version data we should do so.

We also try to reduce the amount of text shown as often the Tcl and Tk
version numbers will be identical; when this happens we should only show
the one version number.

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

git-gui: Make the copyright notice serve double duty.

The copyright notice we display in the about dialog should be the same
as the one at the top of our source code.  By putting the copyright
notice that appears at the top of our source code into a global variable
rather than a comment we can trivially make them the same at all times.

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

git-gui: Be more Macintosh like.

It is tradition for applications to store their about and preferences
menu options within the application menu.  This is the first menu in
the menu bar, just after the apple menu.  Apparently the way to access
this menu from Tk on Mac OS X systems is to create a special menu whose
name ends in ".apple" and place it into the menu bar.

So now if we are on Mac OS X we move our about menu and our options menu
into the application menu, like other Mac OS X applications.

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

git-gui: Added about dialog box.

Created a help menu with an about dialog box.  This about dialog
shows the copyright notice for the application, the fact that it
is covered by the GPL v2.0 or later, the authors, and the current
version of Git it is invoking when users perform actions within it.

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

git-gui: Rename Project menu to Repository.

Since all of the actions in our Project menu actually apply to the
Git concept of a repository, it is a disservice to our users to
call it "project".  This is especially true if Git ever gets any
sort of subproject support, as the term would then most definately
conflict.

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

git-gui: Seperate out the database operations in project menu.

The project menu is just too cluttered without using separator entries
to split out the database operations (such as repack and verify) from
the other options in the same menu.

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

git-gui: Reworded verify console title.

It would be something of a disservice to our users if we refer to
fsck-objects as "verify".  So instead we call it fsck-objects in
the console title, and indicate that's how we are verifying the
object database.

We probably should call our menu option "fsck-objects" or similar
but I really do think that "Verify Database" more accurately describes
the action then "fsck-objects" does, especially to users who aren't
file system developers.

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

git-gui: Don't save amended commit message buffer.

Because we don't automatically restart in amend mode when we quit while
in amend mode the commit message buffer shouldn't be saved to GITGUI_MSG
as it would be misleading when the user restarts the application.

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

git-gui: Allow users to run fsck-objects from the gui.

I recently found a need to run fsck-objects in a number of repositories
that I also use git-gui against.  Tossing in a menu option to invoke
fsck-objects and have its output show up in a console window is simple
enough to do.

We probably need to enhance the console window used by fsck-objects,
like to open up the Git fsck-objects manual page and let the user see
what each message means (such as "dangling commit") and to also let the
user invoke prune, to cleanup any such dangling objects.  But right now
I'm going to ignore that problem in favor of getting other more important
features implemented.

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

git-gui: Improve handling of merge commits.

Its useful to be able to amend the last commit even if it was a merge
commit, so we really should support that in the gui.  We now do so by
making PARENT a list.  We always diff against the first parent but we
create a commit consisting of the parent(s) listed in this list, in
order.

We also should recheck the repository state during an amend.  Earlier
I was bitten by this exact bug when I switched branches through a
command prompt and then did not do a rescan in git-gui.  When I hit
"Amend Last Commit" I was surprised to see information from the prior
branch appear.  This was due to git-gui caching the data from the last
rescan and using that data form the amend data load request, rather than
the data of the current branch.

Improved error text in the dialogs used to tell the user why an amend is
being refused by git-gui.  In general this is only during an initial
commit (nothing prior to amend) and during a merge commit (it is simply
too confusing to amend the last commit while also trying to complete a
merge).

Fixed a couple of minor bugs in the pull logic.  Since this code isn't
really useful nobody has recently tested it and noticed the breakage.
It really needs to be rewritten anyway.

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

git-gui: Correct some state matchings for include/remove.

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

git-gui: Update in memory states after commit.

In order to allow the user to toggle include/exclude from next commit
for files which were partially included in the last commit we need the
current index mode+sha1 data stored in our file_states array.  For
any partially included file we have this information from diff-files,
so we just have to copy it over to the diff-index portion of our state
array.

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

git-gui: Restore the all important shebang line.

Accidentally removed by an unnoticed fat finger accident in vi during
commit 1461c5f3.

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

git-gui: Refactored diff line display formatting logic.

The tags used for diff formatting (which I inherited from gitool) just
didn't make a whole lot of sense, especially if you wanted to try to
match them to the diff output you were seeing on screen.  It did not
help that the diff-index -c output's first two columns are also munged
to make the diff output more user friendly.

So this is a large refactoring of the tags used for diff display.  Now
our tag names match what we put in the left column of each line, which
makes it easier to correlate presentation and implementation.

I removed bold font usage from everything except the hunk headers as I
really did not like the way bold font caused column alignments to become
out of whack within the diff viewer.  It also drew attention to the parts
of the file which were identically changed in both the index and in the
working directory, yet these are usually the parts I find myself caring
the least about.  So its very counter-intuitive.

Lines which are changed differently by both the index and the working
directory are now shown with background colors which span the entire line,
making these lines easier to pick out of the diff.  In general these are
the lines that appear to be more interesting to me when looking at the
3-way diff as they are the ones which contain recent and quite different
changes.

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

git-gui: Updated TODO list now that a task is complete.

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

git-gui: Correct toggling of added/untracked status for new files.

New files also lack index data from diff-files therefore we cannot use
their diff-files index data when we update-index.  Instead we can use
the fact that Git has them hardcoded as "0 0{40}" and do the same thing
ourselves.  This way you can toggle an untracked file into added status
and back out to untracked.

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

git-gui: Describe deleted symlinks in a more friendly way.

Currently core-git's diff utilities report a deleted symlink as a
deleted file with a mode of 120000.  This is not nearly as user
friendly as one might like, as the user must remember that 120000
is the UNIX mode bits for a symlink.  So instead we transform
the not-so-friendly message from core-git into a slightly more
user friendly "deleted symlink" message.

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

git-gui: Fix list loading corruption introduced by 1461c5f3.

Tcl let me assign two different types of values to the variable $n.
Prior to 1461c5f3 $n was the total number of bytes in the string;
but in that commit it also became the current info list for the
current file.  This caused $c < $n to fail as $n was now treated
as 0 and we only loaded the first file in each buffer.

So use a different variable, like $i, instead.

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

git-gui: Correct toggling of deleted file status.

There was a bug with the way we handled deleted file status.  A file
really shouldn't be in D_ state when it has been deleted, instead it
is really DD.  Therefore we should have toggled _D to DD, not D_,
thereby letting us toggle back to _D.

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

git-gui: Make consecutive icon clicks toggle included status of a file.

If the user clicks on the icon associated with a file we now flip to the
inverse status.  Partially included files first fully include, then fully
uninclude, as we don't keep track of intermediate partial inclusions.

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

git-gui: Teach the gui how to uninclude a file.

Sometimes the user may want to keep their working directory file to be
the same content but they don't want it to be part of the current commit
anymore.  In this case we need to undo any changes made to the index
for that file (by reloading the info from HEAD or removing the file
from the index) but leave the working directory alone.

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

git-gui: Don't create PkgInfo on Mac OS X "desktop icons".

Turns out that we really don't need the Contents/PkgInfo file on Mac OS
10.4.  The Finder will still launch the application properly without one.

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

git-gui: Allow adding untracked files in selection.

The previous implementation of do_include_selection did not actually
add files in state _O (untracked, not added) into the repository when
they were in the selection and Commit->Include Selected Files was used.
This was due to the file state filtering logic being the same as that
of Commit->Include All Files, which only considers existing files.

Also fixed a minor issue with rejected attempts to amend an initial
commit.

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

git-gui: Rephrase rescan before commit informational message.

Its not an error that a rescan is required before commit; its just
something we do as a safety feature to try and ensure the user knows
what is going into this commit.  So the dialog should use the info
icon (if one is used by the host OS) rather than the error icon.

Its also not "highly likely" that another Git program modified the
repository, its completely the case.  There is no reason why the
repository would not match our last scanned state unless another
Git program modified the repository (or someone else did so by hand).
So don't be vague about it, own up to the issue and go on with our
business.

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

git-gui: Verify the user has GIT_COMMITTER_IDENT before comitting.

Since git-commit also checks that the user has a GIT_COMMITTER_IDENT
value before it lets the user make a commit we should do the same check
here in git-gui.  We cache the result and assume that the user won't
do something which would change the status of GIT_COMMITTER_IDENT while
we are running.

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

git-gui: Toggle between new commit and amend commit modes.

I was starting to find it annoying that once you entered the 'Amend Last'
mode there was no way to go back to the 'New Commit' mode without quitting
and restarting git-gui.  Its just confusing for the end-user.

Now we can flip back and forth between a new commit and an amend commit
through a pair of radio buttons on the header of the commit buffer area
and through a pair of radio menu buttons in the Commit menu.

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

git-gui: Remove completed items from TODO list.

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

git-gui: Start UI with the index locked.

Because we immediately start a rescan operation, but do so slightly
delayed (by 1 ms, to let the UI show before we start forking off
git processes), we can't let the user try to activate any of the
restricted GUI commands before the 1 ms timer expires and we kick
off the rescan.

So now we lock the index before we enter the Tk event loop, ensuring
that it is impossible for the user to inject a conflicting UI event
before our rescan can begin.

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

git-gui: Misc. comment formatting cleanups.

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

git-gui: Add menu option to include only selected files.

When the user selects a number of files they would typically expect
to be able to act on that selection, such as by including those files
into the next commit.

So we now have a menu option under the Commit menu that lets the user
include only the selection, rather than everything.  If there is no
selection but there is a file in the diff viewer than we consider that
to be the selection (a selection of 1).  Unfortunately we don't disable
this option yet when there's nothing selected to include, but this is
probably not a big deal as there are very few situations where there
are no selected files.

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

git-gui: Refactor file state representations.

It just felt wrong to me that I was using _ as part of the mode argument
to display_file to mean "don't care/use existing" and * as part of
the mode argument to mean "force to _".

So instead use ? to mean "don't care/use existing" and _ to mean
"force to _".  The code is a lot clearer this way and hopefully it
won't drive another developer insane, as it did me.

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

git-gui: Only reshow diff when really necessary.

I noticed that we were reshowing the current diff during a commit;
this occurs because we feed every added and modified file through
update-index just before commit.  During the update-index process
we reshow the current diff if the current file in the diff pane
was one of those added or modified files we reprocessed.  This
just slows down the UI more than is necessary.

So refactoring update_index so that we don't call reshow_diff
from within that code; instead we do it at a higher level.

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

git-gui: Make initial commits work properly.

Apparently I never really tested the logic for making or amending an
initial commit, so although most of the code was here in git-gui it
didn't quite work as it was intended to.

So this is all just bug fixes to make initial commits correctly
generate the list of files going into the initial commit, or to
show a newly added file's diff, and to amend an initial commit.

Because we really want to diff the index against a tree-ish and
there is no such tree-ish on an initial commit we create an empty
tree through git-mktree and diff against that.  This unfortunately
creates a dangling tree, which may confuse a new user who uses
git-gui to make a new commit and then immediately afterwards runs
git fsck-objects to see if their object database is corrupt or not.

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

git-gui: Display error dialog on Mac OS X when no .git found.

If we can't locate a .git directory for the given directory we need to
show a message to the user to let them know the directory wasn't found.
But since this is before we have shown our main application window we
cannot use that as the parent for the error popup; on Mac OS X this
causes an error and prevents the dialog from showing.

Instead only add -parent . to the popup call if we have mapped (shown)
the main window.

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

git-gui: Create a .app file on MacOS X if requested.

If a user works with a repository frequently they may want to just
create an icon they can use to launch git-gui against that repository.

Since we already support this concept on Windows we can do the same on
Mac OS X by creating a .app file with a tiny shell script in it that
sets up the necessary environment then invokes our script.

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

git-gui: Only populate a fetch or push if we have an action.

Don't offer to fetch from a remote unless we have at least one Pull:
line in its .git/remotes/<name> file or at least one configuration
value for remote.<name>.fetch.  Ditto for push.

Users shouldn't be fetching or pushing branch groups unless they
have them configured; anything else is just crazy.

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

git-gui: Handle ' within paths when creating Windows shortcuts.

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

git-gui: Protect ourselves from funny GIT_DIR/working directory setups.

Since we have some serious problems with the GIT_DIR environment variable
on Windows we cannot let the user use a non-standard GIT_DIR with their
working directory.

So require that the GIT_DIR name is actually ".git", that it exists,
and that its parent directory is our working directory.

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

git-gui: Create Windows shortcut icons for git-gui.

If we are running on Windows we now offer a 'Create Desktop Icon' menu
item under the Project menu.  This pops up a save dialog box letting
the user create a .bat file on their desktop (or somewhere else).  The
.bat script will startup Cygwin with a login shell then launch git-gui
in the current working directory.

This is very useful for Windows users who have little to no desire to
start a command window just to run a git-gui session.

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

git-gui: Correctly handle GIT_DIR environment variable.

Some users may want to start us by running "git --git-dir=... gui"
rather than trying to cd into the directory first.  This is especially
true if they want to just make a shortcut to our executable on Windows
and always have that associated with a certain repository.

Since Tcl on Windows throws away our environment and doesn't pass it
down to the child process correctly we cannot call git-rev-parse to
get the GIT_DIR environment variable.  So instead we ask for it
specifically ourselves; if its not defined then we ask rev-parse.
This should actually reduce startup by 1 fork/exec if we were started
as "git gui" as GIT_DIR will be set for us.

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

git-gui: Created makefile to install the program.

Since we want to be installed in gitexecdir so that "git gui" works we
can guess where that directory is by asking the git wrapper executable
and locating ourselves at the same location using the same install
rules as core git.

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

git-gui: Disable diff actions when no diff is active.

There is no reason why the user should be able to operate on the diff
buffer if there is no currently selected diff; likewise the "File:"
label text appears rather silly looking all by itself when no diff
is being shown in the diff buffer.

So now we only enable widgets (like menu items) if there is a diff
currently showing, and we disable them when a diff isn't showing.

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

git-gui: Automatically update-index all included files before commit.

If the user has "Allow Partially Included Files" disabled (and most
probably will as its the default setting) we should run update-index
on every included file before commit to make sure that any changes
made by the user since the last rescan will still be part of this
commit.

If we don't update-index every modified file the user will likely
become confused when part of their changes were committed and other
parts weren't; and those other parts won't show up until a later
rescan occurs.  Since we don't rescan immediately after a commit
this may be a while.

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

git-gui: Allow update_index to also run a script when it completes.

Like rescan we also have cases where we need to perform a script
after we have finished updating a number of files in the index.  By
changing the parameter structure of update_index we can easily pass
through any script we need to run afterwards, such as picking up
in the middle of a commit, or finishing what is left of a rescan.

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

git-gui: Provide an after-rescan script to rescan.

There are some situations where we need to run rescan and have it do
more than just updating the status in the UI when its complete.  To
help with that this changes the rescan procedure to take a script which
it will run at the global level as soon as the rescan is done and the
UI has finished updating with the results.  This is useful for example
if we performed a rescan as part of a commit operation; we can go back
to the commit where we left off when the rescan got initiated.

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

git-gui: Refactor update_status -> rescan.

Since we refer to the act of updating our memory structures with index
and working directory differences as a rescan in the UI its probably
a good idea to make the related procedures have the same name.

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

git-gui: Implemented multiple selection in file lists.

Because I want to let users apply actions to more than one file at
a time we really needed a concept of "the current selection" from
the two file lists.

Since I'm abusing a Tk text widget for the file displays I can't
really use the Tk selection to track which files are picked and
which aren't.  So instead we keep this in an array to tell us
which paths are currently selected and we use an inverse fg/bg
for the selected file display.  This is common most operating
systems as a selection indicator.

The selection works like most users would expect; single click will
clear the selection and pick only that file, M1-click (aka Ctrl-click
or Cmd-click) will toggle the one file in/out of the selection, and
Shift-click will select the range between the last clicked file and
the currently clicked file.

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

git-gui: Narrow the no differences information message.

On Mac OS X the no differences informational message was linewrapped
at the wrong points due to the limited width of the system dialog,
yet the LFs embedded in the message (where I linewrapped it manually)
were also being honored.  This resulted in a very difficult to read
paragraph of text.

So this narrows the text down by another 10 columns or so, making it
more readable.

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

git-gui: Refactor mouse clicking on file names/icons.

I'm not a huge fan of putting the left and right mouse actions into
the same procedure.  Originally this is how Paul had implemented the
logic in gitool and I had carried some of that over into git-gui, but
now that I'm getting ready to implement right mouse click features to
act on files I really should split this apart.

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

git-gui: By default don't allow partially included files.

The concept of the Git index is confusing for many users, especially
those who are newer to Git.

Since git-gui is (at least partially) intended to be used by newer
users who don't need the complexity of the index to be put in front
of them early on, we should hide it by making any partially included
file fully included as soon as we identify it.  To do this we just
run a quick update_index pass on any file which differs both in the
index and the working directory, as these files have already been
at least partially included by the user.

A new option has been added in the options dialog (gui.partialinclude)
which lets the user enable accessing the index from git-gui.  This
just disables the automatic update_index pass on partially included
files.

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

git-gui: Reverted file name text field to a label.

So although a text field with a flat relief looks like a label on
Windows it doesn't on Mac OS X.  The Aqua version of Tk is still
drawing a border around the text field and that makes the diff pane
header look pretty ugly.

Earlier I had made the file name area into a text widget so the user
could highlight parts of it and copy them onto the clipboard; but with
the context menu being present this isn't quite as necessary as the user
can copy the file name to the clipboard using that instead.  So although
this is a small loss in functionality for non-Mac OS X systems I think it
is still reasonable.

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

git-gui: Minor UI layout improvements for console windows.

Moved the Close button over to the lower right corner where our
Cancel/Save buttons are in the options dialog.  This should fit
better with our own look and feel as well as that of most apps
on Mac OS X and Windows.

Also set the lower status bar in a console window to indicate the
process is working and that the user should wait for it to finish.

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

git-gui: Display status on left in diff header.

Because the Tk pack layout manager gives all space to the right/bottom
most widget during expand/contract of the frame we were adding and
removing all space from the status area of the bar and not from the
file name, which is what we actually wanted.

A simple enough fix is to just put the status of the given file on
the left side of the diff viewer header rather than on the right.

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

git-gui: Correct language for M_/A_ status codes.

When I changed from 'check in' to 'include' I missed the human friendly
status displayed in the right side of the diff viewer heading.  It was
still reporting 'Checked in' for a fully included file, which is not
what we wanted it to say.

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

git-gui: Allow the user to copy name of the file in the diff viewer.

There's a lot of reasons why the user might need to obtain the
complete (or just part of) path of a file which they are currently
viewing in the diff viewer pane.  So now we allow selection on this
widget by using a text widget instead of a label.  We also offer a
context menu which has actions for copying the selection or the entire
value onto the clipboard.

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

git-gui: Use a smaller pipe buffer for update-index.

When we shove a large number of files at update-index and they have
very short path names we are likely going to fit a large number of
them into the pipe buffer very early; thereby seeing a huge progress
update followed by lots of waiting between progress updates due to
the latency of update-index.

Using a smaller buffer should help smooth out the progress updates
as we are better able to keep tabs on the update-index process'
progress through our list of paths.

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

git-gui: Sort the list of paths being updated in the index.

Its a little surprising to see the UI update the icons for files
in random order, due to the fact that the files are updating in
the order they appear within the array (which is based on a hash
function and not order).  So sort the list of files before we send
any to update-index so the order of operation is means something to
the user.

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

git-gui: Allow the user to control the number of context lines in a diff.

When displaying a diff the Git default of 3 line of context may not be
enough for a user to see what has actually changed.  Consequently we
set our own program default to 5 lines of context and then allow the
user to adjust this on a per-repository and global level through our
options dialog.

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

git-gui: Cleanup diff construction code to prepare for more options.

I'd like to allow the user to have more control over how we format
the diff in the diff viewer; to that end we need to add additional
options to the diff-index command line as we construct the command
for execution.

So cleanup the command handling code now to use lappend so we can
come back and add in our additional options.

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

git-gui: Reshow diff if we sent the file to update-index.

We can't ask the diff viewer to recompute the diff until after our
update-index child process terminates, as the diff programs need to
be able to read the updated index in order to generate the correct
diff.  This is actually why we prevent diffs from being generated
while there is an update lock on the index, which is why we ignored
our own show_diff invocation in the middle of the write_update_index
event handler.

So now we mark a flag if we identify that the file currently in the
diff viewer was also sent to update-index; then later when the
update-index process has terminated we update the diff viewer if
the flag is true.

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

git-gui: Always use eq/ne for string comparsions.

This is one of those stupid Tcl mistakes that an experienced Tcl
programmer just wouldn't make.  We should always use eq and ne to
compare string values (and never == or !=) as when we use ==/!=
Tcl will attempt to convert either side to numeric if one of the
two sides looks like a numeric.  This could cause some trouble if
a file named "1" exists and a different file named "1.0" also exists;
their paths are equal according to == but not according to eq.

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

git-gui: Added post-commit invocation after the commit is done.

Since git-commit.sh invokes hooks/post-commit after running git rerere
we should do the same if its available and executable.

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

git-gui: Remove the commit_active global variable.

We were originally trying to use $commit_active to tell us if there was
a commit currently in progress, just so we didn't attempt to start a
second (parallel) one by mistake.  But really the index lock handles
this for us as it won't let us lock the index if it is already locked
for update.  So this can't happen.

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

git-gui: Run the pre-commit hook in the background.

I started to notice on Windows that commits took a lot longer to get
going than on my Mac OS X system.  The real reason is the repositories
that I'm testing with on Windows all enabled the standard pre-commit hook
while my test repository on Mac OS X doesn't have it executable (so its
not running).  So the Windows repositories are spending this
lag time running that hook.

Now we run the pre-commit hook in the background, allowing the UI to
update and tell the user we are busy doing things.

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