tokkee.org

git-gui: Force focus to the diff viewer on mouse click.

Apparently a "feature" of Tcl/Tk on Mac OS X is that a disabled text
widget cannot receive focus or receive a selection within it.  This
makes the diff viewer almost useless on that platform as you cannot
select individual parts of the buffer.

Now we force focus into the diff viewer when its clicked on with
button 1.  This works around the feature and allows selection to
work within the viewer just like it does on other less sane systems,
like Microsoft Windows.

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

git-gui: Unset unnecessary UI setup variable.

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

git-gui: Cleanup end-of-line whitespace in commit messages.

When committing changes its useless to have trailing whitespace on the
end of a line within the commit message itself; this serves no purpose
beyond wasting space in the repository.  But it happens a lot on my
Mac OS X system if I copy text out of a Terminal.app window and paste
it into git-gui.

We now clip any trailing whitespace from the commit buffer when loading
it from a file, when saving it out to our backup file, or when making
the actual commit object.

I also fixed a bug where we lost the commit message buffer if you quit
without editing the text region.  This can happen if you quit and restart
git-gui frequently in the middle of an editing session.

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

git-gui: Elide CRs appearing in diff output from display.

If we are displaying a diff for a DOS-style (CRLF) formatted file then
the Tk text widget would normally show the CR at the end of every line;
in most fonts this will come out as a square box.  Rather than showing
this character we'll tag it with a tag which forces the character to
be elided away, so its not displayed.  However since the character is
still within the text buffer we can still obtain it and supply it over
to `git apply` when staging or unstaging an individual hunk, ensuring
that the file contents is always fully preserved as-is.

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

git-gui: Allow staging/unstaging individual diff hunks.

Just like `git-add --interactive` we can now stage and unstage individual
hunks within a file, rather than the entire file at once.  This works
on the basic idea of scanning backwards from the mouse position to
find the hunk header, then going forwards to find the end of the hunk.
Everything in that is sent to `git apply --cached`, prefixed by the
diff header lines.

We ignore whitespace errors while applying a hunk, as we expect the
user's pre-commit hook to catch any possible problems. This matches
our existing behavior with regards to adding an entire file with
no whitespace error checking.

Applying hunks means that we now have to capture and save the diff header
lines, rather than chucking them.  Not really a big deal, we just needed
a new global to hang onto that current header information.  We probably
could have recreated it on demand during apply_hunk but that would mean
we need to implement all of the funny rules about how to encode weird
path names (e.g. ones containing LF) into a diff header so that the
`git apply` process would understand what we are asking it to do.  Much
simpler to just store this small amount of data in a global and replay
it when needed.

I'm making absolutely no attempt to correct the line numbers on the
remaining hunk headers after one hunk has been applied.  This may
cause some hunks to fail, as the position information would not be
correct.  Users can always refresh the current diff before applying a
failing hunk to work around the issue.  Perhaps if we ever implement
hunk splitting we could also fix the remaining hunk headers.

Applying hunks directly means that we need to process the diff data in
binary, rather than using the system encoding and an automatic linefeed
translation.  This ensures that CRLF formatted files will be able to be
fed directly to `git apply` without failures.  Unfortunately it also means
we will see CRs show up in the GUI as ugly little boxes at the end of
each line in a CRLF file.

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

git-gui: Only allow Refresh in diff context menu when we have a diff.

There is no reason to attempt refreshing an empty diff viewer, so
the Refresh option of our diff context menu should be disabled when
there is no diff currently shown.

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

git-gui: Display the size of the pack directory.

Just as we show the amount of disk space taken by the loose objects,
its interesting to know how much space is taken by the packs directory.
So show that in our Database Statistics dialog.

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

git-gui: Use system default labelframe bordering.

In the new branch dialog and delete branch dialog we are using the
system default labelframe border settings (whatever those are) and
they look reasonable on both Windows and Mac OS X.  But for some
unknown reason to me I used a raised border for the options dialog.
It doesn't look consistent anymore, so I'm switching it to the
defaults.

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

git-gui: Implement basic branch switching through read-tree.

If the user selects a different branch from the Branch menu, or asks
us to create a new branch and immediately checkout that branch we
now perform the update of the working directory by way of a 2 way
read-tree invocation.

This emulates the behavior of `git checkout branch` or the behavior
of `git checkout -b branch initrev`.  We don't however support the
-m style behavior, where a switch can occur with file level merging
performed by merge-recursive.  Support for this is planned for a
future update.

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

git-gui: Display database stats (count-objects -v) on demand.

Its nice to know how many loose objects and roughly how much disk space
they are taking up, so that you can guestimate about when might be a
good time to run 'Compress Database'.  The same is true of packfiles,
especially once the automatic keep-pack code in git-fetch starts to
be more widely used.

We now offer the output of count-objects -v in a nice little dialog
hung off the Repository menu.  Our labels are slightly more verbose
than those of `count-objects -v`, so users will hopefully be able
to make better sense of what we are showing them here.

We probably should also offer pack file size information, and data
about *.idx files which exist which lack corresponding *.pack files
(a situation caused by the HTTP fetch client).  But in the latter
case we should only offer the data once we have way to let the user
clean up old and inactive index files.

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

git-gui: Handle commit encoding better.

Git prefers that all log messages are encoding in UTF-8.  So now when
git-gui generates the commit message it converts the commit message
text from the internal Tcl Unicode representation into a UTF-8 file.
The file is then fed as stdin to git-commit-tree.  I had to start
using a file here rather than feeding the message in with << as
<< uses the system encoding, which we may not want.

When we reload a commit message via git-cat-file we are getting the
raw byte stream, with no encoding performed by Git itself.  So unless
the new 'encoding' header appears in the message we should probably
assume it is utf-8 encoded; but if the header is present we need to
use whatever it claims.

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

git-gui: Honor system encoding for filenames.

Since git operates on filenames using the operating system encoding
any data we are receiving from it by way of a pipe, or sending to it
by way of a pipe must be formatted in that encoding.  This should
be the same as the Tcl system encoding, as its the encoding that
applications should be using to converse with the operating system.

Sadly this does not fix the gitweb/test file in git.git on Macs;
that's due to something really broken happening in the filesystem.

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

git-gui: Remove spurious newline in untracked file display.

This newline is stupid; it doesn't get put here unless the file
is very large, and then its just sort of out of place.

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

git-gui: Don't try to tag the 'Binary files * and * differ' line.

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

git-gui: When possible show the type of an untracked file.

Users may want to know what a file is before they add it to the
repository, especially if its a binary file.  So when possible
invoke 'file' on the path and try to get its output.  Since
this is strictly advice to the user we won't bother to report
any failures from our attempt to run `file`.

Since some file commands also output the path name they were
given we look for that case and strip it off the front of the
returned output before placing it into the diff viewer.

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

git-gui: Limit display of large untracked files.

Our internal diff viewer displays untracked files to help users see if
they should become tracked, or not.  It is not meant as a full file
viewer that handles any sort of input.  Consequently it is rather
unreasonable for users to expect us to show them very large files.
Some users may click on a very big file (and not know its very big)
then get surprised when Tk takes a long time to load the content and
render it, especially if their memory is tight and their OS starts to
swap processes out.

Instead we now limit the amount of data we load to the first 128 KiB
of any untracked file.  If the file is larger than 128 KiB we display
a warning message at the top of our diff viewer to notify the user
that we are not going to load the entire thing.  Users should be able
to recognize a file just by its first 128 KiB and determine if it
should be added to the repository or not.

Since we are loading 128 KiB we may as well scan it to see if the
file is binary.  So I've removed the "first 8000 bytes" rule and
just allowed git-gui to scan the entire data chunk that it read in.
This is probably faster anyway if Tcl's [string range] command winds
up making a copy of the data.

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

git-gui: Don't show content of untracked binary files.

A binary file can be very large, and showing the complete content of
one is horribly ugly and confusing.  So we now use the same rule that
core Git uses; if there is a NUL byte (\0) within the first 8000 bytes
of the file we assume it is binary and refuse to show the content.

Given that we have loaded the entire content of the file into memory
we probably could just afford to search the whole thing, but we also
probably should not load multi-megabyte binary files either.

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

git-gui: Always start a rescan on an empty diff.

If we got an empty diff its probably because the modification time of
the file was changed but the file content hasn't been changed.  Typically
this happens because an outside program modified the file and git-gui
was told to not run 'update-index --refresh', as the user generally
trusts file modification timestamps.  But we can also get an empty diff
when a program undos a file change and still updates the modification
timestamp upon saving, but has undone the file back to the same as what
is in the index or in PARENT.

So even if gui.trustmtime is false we should still run a rescan on
an empty diff.  This change also lets us cleanup the dialog message
that we show when this case occurs, as its no longer got anything to
do with Trust File Modification Timestamps.

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

git-gui: Ignore 'No newline at end of file' marker line.

If one or both versions of the file don't have a newline at the end
of the file we get a line telling us so in the diff output.  This
shouldn't be tagged, nor should it generate a warning about not
being tagged.

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

git-gui: Fix 'Select All' action on Windows.

Sometimes the Select All action from our context menus doesn't work
unless the text field its supposed to act on has focus.  I'm not
really sure why adding the sel tag requires having focus.  It
technically should not be required to update the sel tag membership,
but perhaps there is a bug in Tcl/Tk 8.4.1 on Windows which is
causing this odd behavior.

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

git-gui: Don't attempt to tag new file/deleted file headers in diffs.

We don't want to tag these new file/delete file lines, as they aren't
actually that interesting.  Its quite clear from the diff itself that
the file is a new file or is a deleted file (as the entire thing will
appear in the diff).

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

git-gui: Force an update-index --refresh on unchanged files.

Its possible for external programs to update file modification dates of
many files within a repository.  I've seen this on Windows with a popular
virus scanner, sadly enough.  If the user has Trust File Modification
Timestamp enabled and the virus scanner touches a large number of files
it can be annoying trying to clear them out of the 'Changed But Not
Updated' file list by clicking on them one at a time to load the diff.

So now we force a rescan as soon as one such file is found, and for
just that rescan we disable the Trust File Modification Timestamp option
thereby allowing Git to update the modification dates in the index.

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

git-gui: Don't format the mode line of a diff.

We sometimes see a mode line show up in a diff if the file mode was
changed.  But its not something we format specially.

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

git-gui: Create missing branch head on initial commit.

If we are making an initial commit our branch head did not exist when
we scanned for all heads during startup.  Consequently we won't have
it in our branch menu.  So force it to be put there after the ref was
created.

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

git-gui: Slightly tweak new window geometry.

I didn't really like the way a new git-gui launched in a new repository
as the window geometry wasn't quite the best layou.  So this is a minor
tweak to try and get space distributed around the window better.

By decreasing the widths we're also able to shrink the gui smaller
without Tk clipping content at the edge of the window.  A nice feature.

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

git-gui: Update todo list with finished and new items.

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

git-gui: Correctly categorize tracking branches and heads.

Up until now git-gui did not support the new wildcard syntax used to
fetch any remote branch into a tracking branch during 'git fetch'. Now
if we identify a tracking branch as ending with the string '/*' then
we use for-each-ref to print out the reference names which may have
been fetched by that pattern.  We also now correctly filter any
tracking branches out of refs/heads, if they user has placed any there.

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

git-gui: Automatically toggle the relevant radio buttons.

When the user selects a starting revision from one of our offered popup
lists (local branches or tracking branches) or enters in an expression
in the expression input field we should automatically activate the
corresponding radio button for them.

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

git-gui: Fully select a field when entering into it.

If the user is tabbing through fields in the options dialog they are
likely to want to just enter a new value for the field, rather than
edit the value in-place.  This is easier if we select the entire value
upon focusing into the field.

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

git-gui: Improve keyboard traversal in dialogs.

When we are in a dialog such as the new branch dialog or our options
dialog we should permit the user to traverse around through the available
widgets with their Tab/Shift-Tab key combinations.  So in any single
line text field where we don't want tab characters to actually be
inserted into the value rebind Tab and Shift-Tab to honor what the
tk_focusPrev and tk_focusNext scripts recommend.

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

git-gui: Allow user to specify a branch name pattern.

Typically I'm creating all new branches with the same prefix, e.g. 'sp/'.
So its handy to be able to setup a repository (or global) level config
option for git gui which contains this initial prefix.  Once set then
git-gui will load it into the new branch name field whenever a new
branch is being created.

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

git-gui: Give a better error message on an empty branch name.

New branches must have a name.  An empty one is not a valid ref, but the
generic message "We do not like '' as a branch name." is just too vague
or difficult to read.  So detect the missing name early and tell the
user it must be entered.

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

git-gui: Don't offer tracking branches if none exist.

I refactored the common code related to tracking branch listing into
a new procedure all_tracking_branches.  This saves a few lines and
should make the create and delete dialogs easier to maintain.

We now don't offer a radio button to create from a tracking branch
or merge-check a tracking branch if there are no tracking branches
known to git-gui.  This prevents us from creating an empty option
list and letting the user try to shoot themselves in the foot by
asking us to work against an empty initial revision.

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

git-gui: Never line wrap in file lists.

Some of my file paths in some of my repositories are very long, this
is rather typical in Java projects where the path name contains a deep
package structure and then the file name itself is rather long and
(hopefully) descriptive.  Seeing these paths line wrap in the file lists
looks absolutely horrible.  The entire rendering is almost unreadable.

Now we draw both horizontal and vertical scrollbars for both file lists,
and we never line wrap within the list text itself.

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

git-gui: Make diff viewer colors match gitk's defaults.

Because users who use git-gui are likely to also be using gitk, we
should at least match gitk's default colors and formatting within the
diff viewer.

Unfortunately this meant that I needed to change the background colors
of the hunks in a 'diff --cc' output, as the green used for 'added line'
was completely unreadable on the old color.  We now use ivory1 to show
hunks which came from HEAD/parent^1, which are the portions that the
current branch has contributed, and are probably the user's own changes.
We use a very light blue for the portions which came from FETCH_HEAD,
as this makes the changes made by the other branch stand out more in the
diff.

I've also modified the hunk header lines to be blue, as that is how gitk
is showing them.

Apparently I forgot to raise the sel tag above everything else in the
diff viewer, which meant that selections in the diff viewer were not
visible if they were made on a 'diff --cc' hunk which had a background.
Its now the higest priority tag, ensuring the selection is always visible
and readable.

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

git-gui: Correctly ignore '* Unmerged path' during diff.

If a path is really unmerged, such as because it has been deleted and
also modifed, we cannot obtain a diff for it.  Instead Git is sending
back '* Unmerged path <blah>' for file <blah>.  We should display this
line as-is as our tag selecting switches don't recognize it.

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

git-gui: Change rude error popup to info popup.

If the user has not added any files yet they cannot commit.  But
telling them this isn't an error, its really just an informational
note meant to push the user in the correct direction.

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

git-gui: Improve the merge check interface for branch deletion.

Just like how we split out the local and remote branches into two
different pick lists for branch creation, we should do the same
thing for branch deletion.  This means that  there are really 3
modes of operation here:

  * delete only if merged into designated local branch;
  * delete only if merged into designated tracking (remote) branch;
  * delete no matter what

So we now use radio buttons to select between these operations.

We still default to checking for merge into the current branch,
as that is probably the most commonly used behavior. It also is
what core Git's command line tools do.

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

git-gui: Use a grid layout for branch dialog.

Using a stack of frames in the Starting Revision section of the new
branch dialog turned out to be a mess.  The varying lengths of each
label caused the optionMenu widgets to be spread around the screen
at unaligned locations, making the interface very kludgy looking.

Now we layout the major sections of the branch dialog using grid
rather than pack, allowing these widgets to line up vertically in
a nice neat column.  All extra space is given to column 1, which is
where we have located the text fields.

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

git-gui: Pad new branch name input box.

The new branch name input box was showing up too close to the labelframe
border, it was basically right on top of it on Windows.  This didn't
look right when compared to the Starting Revision's expression input
field, as that had a 5 pixel padding.

So I've put the new name input box into its own frame and padded that
frame by 5 pixels, making the UI more consistent.

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

git-gui: Correct unmerged file detection at commit time.

Its impossible to commit an index which has unmerged stages.

Unfortunately a bug in git-gui allowed the user to try to do exactly that,
as we broke out of our file scanning loop as soon as we found a valid AMD
index state.  That's wrong, as the files are coming back from our array
in pseudo-random order; an unmerged file may get returned only after all
merged files.

I also noticed the grammer around here in our dialog boxes still used
the term 'include', so this has been updated to reflect current usage.

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

git-gui: Add Refresh to diff viewer context menu.

Sometimes you want to just force the diff to redisplay itself without
rescanning every file in the filesystem (as that can be very costly
on large projects and slow operating systems).  Now you can force a
diff-only refresh from the context menu.  Previously you could also
do this by reclicking on the file name in the UI, but it may not be
obvious to all users, having a context menu option makes it more
clear.

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

git-gui: Correct disappearing unstaged files.

A prior commit tried to use the old index state for the old working
directory state during a UI refresh of a file.  This caused files
which were being unstaged (and thus becoming unmodified) to drop
out of the working directory side of the display, at least until
the user performed a rescan to force the UI to redisplay everything.

Signed-off-by: Shawn O. Pearce <spearce@spearce.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>