tokkee.org

git-gui: Clear diff from viewer if the side changed.

If the user switches the currently shown file from one side of the UI
to the other then how its diff is presented would be different.  And
leaving the old diff up is downright confusing.

Since the diff is probably not interesting to the user after the switch
we should just clear the diff viewer.  This saves the user time, as they
won't need to wait for us to reload the diff.

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

git-gui: Fix bug in unmerged file display.

We were not correctly setting the old state of an index display to
_ if the index was previously unmerged.   This caused us to try and
update a U->M when resolving a merge conflict but we were unable to
do so as the icon did not exist in the index viewer.  Tk did not
like being asked to modify an icon which was undefined.

Now we always transform both the old and the new states for both
sides (index and working directory) prior to updating the UI.

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

git-gui: Improve diff --cc viewing for unmerged files.

Now that we are using 'git diff' to display unmerged working directory
files we are getting 'diff --cc' output rather than 'diff --combined'
output.  Further the markers in the first two columns actually make
sense here, we shouldn't attempt to rewrite them to something else.

I've added 'diff --cc *' to the skip list in our diff viewer, as that
particular line is not very interesting to display.

I've completely refactored how we perform detection of the state of a
line during diff parsing; we now report an error message if we don't
understand the particular state of any given line.  This way we know
if we aren't tagging something we maybe should have tagged in the UI.

I've also added special display of the standard conflict hunk markers
(<<<<<<<, =======, >>>>>>>).  These are formatted without a patch op
as the patch op is always '+' or '++' (meaning the line has been added
relative to the committed state) and are displayed in orange bold text,
sort of like the @@ or @@@ marker line is at the start of each hunk.

In a 3 way merge diff hunks which came from our HEAD are shown with a
azure2 background, and hunks which came from the incoming MERGE_HEAD
are displayed with a 'light goldenrod yellow' background.  This makes
the two different hunks clearly visible within the file.  Hunks which
are ++ or -- (added or deleted relative to both parents) are shown
without any background at all.

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

git-gui: Improve the display of merge conflicts.

If a file has a merge conflict we want it to show up in the 'Changed
But Not Updated' file list rather than the 'Changes To Be Committed'
file list.  This way the user can mostly ignore the left side (the
HEAD<->index comparsion) while resolving a merge and instead focus
on the merge conflicts, which are just shown on the right hand side.

This requires detecting the U state in the index side and drawing
it as though it were _, then forcing the working directory side to
have a U state.  We have to delay this until presentation time as
we don't want to change our internal state data to be different
from what Git is telling us (I tried, the patch for that was ugly
and didn't work).

When showing a working directory diff and its a merge conflict we
don't want to use diff-files as this would wind up showing any
automatically merged hunks obtained from MERGE_HEAD in the diff.
These are not usually very interesting as they were completed by
the system.  Instead we just want to see the conflicts.  Fortunately
the diff porcelain-ish frontend (aka 'git diff') detects the case of
an unmerged file and generates a --cc diff against HEAD and MERGE_HEAD.
So we now force any working directory diff with an index state of 'U'
to go through that difference path.

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

git-gui: Remove combined diff showing behavior.

The combined diff format can be very confusing, especially to new users
who may not even be familiar with a standard two way diff format.  So
for files which are already staged for commit and which are modifed in
the working directory we should show two different diffs, depending on
which side the user clicked on.

If the user clicks on the "Changes To Be Committed" side then we should
show them the PARENT<->index difference.  This is the set of changes they
will actually commit.

If the user clicks on the "Changed But Not Updated" side we should show
them the index<->working directory difference.  This is the set of changes
which will not be committed, as they have not been staged into the index.
This is especially useful when merging, as the "Changed But Not Updated"
files are the ones that need merge conflict resolution, and the diff here
is the conflict hunks and/or any evil merge created by the user.

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

git-gui: Refactor current_diff -> current_diff_path.

We now need to keep track of which side the current diff is for,
HEAD<->index or index<->working directory.  Consequently we need
an additional "current diff" variable to tell us which side the
diff is for.  Since this is really only necessary in reshow_diff
I'm going to declare a new global, rather than try to shove both
the path and the side into current_diff.

To keep things clear later on, I'm renaming current_diff to
current_diff_path.  There is no functionality change in this
commit.

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

git-gui: Attempt to checkout the new branch after creation.

If the user asked us to checkout the branch after creating it then
we should try to do so.  This may fail, especially right now since
branch switching from within git-gui is not supported.

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

git-gui: Don't delete the test target branch.

Its possible for the user to select a branch for the merge test
(while deleting branches) and also select that branch for deletion.
Doing so would have bypassed our merge check for that branch, as
a branch is always a strict subset of itself.  So we will simply
skip over a branch and not delete it if that is the branch which
the user selected for the merge check.

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

git-gui: Improve the branch delete confirmation dialogs.

If the user is deleting a branch which is fully merged into the
selected test branch we should not confirm the delete with them,
the fact that the branch is fully merged means we can recover the
branch and no work will be lost.

If a branch is not fully merged, we should warn the user about which
branch(es) that is and continue deleting those which are fully merged.

We should only delete a branch if the user disables the merge check,
and in that case we should confirm with the user that a delete should
occur as this may cause them to lose changes.

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

git-gui: Move commit_prehook into commit_tree.

The only reason the commit_prehook logic was broken out into its own
proc was so it could be invoked after the current set of files that
were already added to the commit could be refreshed if 'Allow Partially
Added Files' was set to false.  Now that we no longer even offer that
option to the user there is no reason to keep this code broken out
into its own procedure.

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

git-gui: Remove 'Allow Partially Added Files' option.

Now that we take the approach of core Git where we allow the user to
stage their changes directly into the index all of the time there is
absolutely no reason to have the Allow Partially Added Files option,
nor is there a reason or desire to default that option to false.

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

git-gui: Use borders on text fields in branch dialog.

On Mac OS X wish does not draw borders around text fields, making the
field look like its not even there until the user focuses into it. I
don't know the Mac OS X UI standards very well, but that just seems
wrong.  Other applications (e.g. Terminal.app) show their input boxes
with a sunken relief, so we should do the same.

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

git-gui: Allow creating branches from tracking heads.

Sometimes you want to create a branch from a remote tracking branch.
Needing to enter it in the revision expression field is very annoying,
so instead let the user select it from a list of known tracking branches.

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

git-gui: Allow users to delete branches merged upstream.

Most of the time when you are deleting branches you want to delete
those which have been merged into your upstream source.  Typically
that means it has been merged into the tip commit of some tracking
branch, and the current branch (or any other head) doesn't matter.

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

git-gui: Implemented local branch deletion.

Users can now delete a local branch by selecting from a list of
available branches.  The list automatically does not include
the current branch, as deleting the current branch could be quite
dangerous and should not be supported.

The user may also chose to have us verify the branches are fully
merged into another branch before deleting them.  By default we
select the current branch, matching 'git branch -d' behavior,
but the user could also select any other local branch.

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

git-gui: Bind M1-N to create branch.

Creating branches is a common enough activity within a Git project
that we probably should give it a keyboard accelerator.  N is not
currently used and seems reasonable to stand for "New Branch". To
bad our menu calls it create.

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

git-gui: Implemented create branch GUI.

Users may now create new branches by activating the Branch->Create menu
item.  This opens a dialog which lets the user enter the new branch
name and select the starting revision for the new branch.

For the starting revision we allow the user to either select from a
list of known heads (aka local branches) or to enter an arbitrary
SHA1 expression.  For either creation technique we run the starting
revision through rev-parse to verify it is valid before trying to
create the ref with update-ref.

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

git-gui: Pad the cancel/save buttons in the options window.

It looks horrible to have the cancel and save buttons wedged up against
each other in our options dialog.  Therefore toss a 5 pixel pad between
them.

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

git-gui: Only permit selection in one list at a time.

Now that our lists represent more defined states it no longer makes any
sense to permit a user to make selections from both lists at once, as
the each available operation acts only on files whose status corresponds
to only one of the lists.

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

git-gui: Simplify printing of index info to update-index.

During unstaging we can simplify the way we perform the output by
combining our four puts into a single call.

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

git-gui: Refactor the add to commit state filters.

The list of states which are valid for update-index were a little
too verbose and fed a few too many cases to the program.  We can
do better with less lines of code by using more pattern matching,
and since we already were globbing here there's little change in
runtime cost.

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

git-gui: Refactor the revert (aka checkout-index) implementation.

We can revert any file which has a valid stage 0 (is not unmerged)
and which is has a working directory status of M or D.  This vastly
simplifies our pattern matching on file status when building up the
list of files to perform a checkout-index against.

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

git-gui: Add or unstage based on the specific icon used.

Rather than relying on the file state and just inverting it, we should
look at which file icon the user clicked on.  If they clicked on the
one in the "Changes To Be Committed" list then they want to unstage
the file.  If they clicked on the icon in the "Changed But Not Updated"
list then they want to add the file to the commit.  This should be much
more reliable about capturing the user's intent then looking at the file
state.

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

git-gui: Refactor add/remove proc names to align with reality.

Now that core Git refers to resetting paths in the index as "unstaging"
the paths we should do the same in git-gui, both internally in our code
and also within the menu action name.  The same follows for our staging
logic, as core Git refers to this as 'add'.

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

git-gui: Cleanup state descriptions.

Updated the state descriptions for individual file states to try and
make them more closely align with what git-runstatus might display.
This way a user who is reading Git documentation will be less confused
by our descriptions.

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

git-gui: Remove invalid DM state.

The DM state cannot really happen.  Its implying that the file has
been deleted in the index, but the file in the working directory has
been modified relative to the file in the index.  This is complete
nonsense, the file doesn't exist in the index for it to be different
against!

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

git-gui: Correct DD file state to be only D_.

Apparently my earlier suspicion that the file state DD was a bug was
correct.  A file which has been deleted from the working directory and
from the index will always get the state of D_ during a rescan.  Thus
the only valid state for this to have is D_.  We should always use only
D_ internally during our state changes.

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

git-gui: Convert UI to use 'staged for commit' interface.

This is a rather drastic change to the git-gui user interface, but it
doesn't really look any different yet.  I've taken the two lists and
converted them to being "changes to be committed" and "changed but
not updated".  These lists correspond to the same lists output by
git-runstatus based on how files differ in the HEAD<->index and the
index<->working directory comparsions it performs.

This change is meant to correlate with the change in Git 1.5.0 where
we have brought the index more into the foreground and are trying to
teach users to make use of it as part of their daily operations.

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

git-gui: Start file status display refactoring.

I'm going to refactor the way file status information gets displayed
so it more closely aligns with the way 'git-runstatus' displays the
differences between HEAD<->index and index<->working directory.  To
that end the other file list is going to be changed to be the working
directory difference.  So this change renames it.

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

git-gui: Display the directory we are entering during startup.

If the user has many git-gui icons it may be confusing when they
start one which git-gui is still coming up.  So on the windows
systems we now include an echo statement which displays the full
pathname of the working directory we are trying to enter into.

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

git-gui: Make the gitk starting message match our usual format.

Because we usually say "Operation... please wait..." we should do
the same thing when starting gitk.

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

git-gui: Allow [gitdir ...] to act as [file join [gitdir] ...].

Because it is such a common idiom to use [gitdir] along with [file join]
to locate the path of an item within the .git directory of the current
repository we might as well allow gitdir to act as a wrapper for the
file join operation.

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

git-gui: Cleanup usage of gitdir global variable.

The gitdir global variable is essentially read-only, and is used rather
frequently.  So are appname and reponame.  Needing to constantly declare
'global appname' just so we can access the value as $appname is downright
annoying and redundant.  So instead I'm declaring these as procedures and
changing all uses to invoke the procedure rather than access the global
directly.

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

git-gui: Refactor reponame computation.

We use reponame in a number of locations, and every time its always the
same value.  Instead of computing this multiple times with code that was
copied and pasted around we can compute it once immediately after the
global gitdir has been computed and set.

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

git-gui: Suggest when running 'git gc' may be worthwhile.

Users often forget to repack their object database, then start to
complain about how slow it is to perform common operations after
they have collected thousands of loose objects in their objects
directory.  A simple repack usually restores performance.

During startup git-gui now asks git-count-objects how many loose
objects exist, and if this number exceeds a hardcoded threshold
we suggest that the user compress the database (aka run 'git gc')
at this time.  I've hardcoded this to 2000 objects on non-Windows
systems as there the filesystems tend to handle the ~8 objects
per directory just fine.  On Windows NTFS and FAT are just so slow
that we really start to lag when more than 200 loose objects exist,
so the hardcoded threshold is much lower there.

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

git-gui: Don't offer my miga hack if its configuration file isn't present.

I really hate that I have this specialized hack within git-gui, but
its here.  The hack shouldn't be offered unless miga's required .pvcsrc
file is in the top level of the repository's working directory.  If
this file is missing miga will fail to startup properly, and the user
cannot wouldn't be able to use it within this directory.

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

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>