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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 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: 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>
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>
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>
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>
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: 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 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>
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>
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>
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>
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>
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>
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>
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: 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>