Its not an error that a rescan is required before commit; its just
something we do as a safety feature to try and ensure the user knows
what is going into this commit. So the dialog should use the info
icon (if one is used by the host OS) rather than the error icon.
Its also not "highly likely" that another Git program modified the
repository, its completely the case. There is no reason why the
repository would not match our last scanned state unless another
Git program modified the repository (or someone else did so by hand).
So don't be vague about it, own up to the issue and go on with our
business.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git-commit also checks that the user has a GIT_COMMITTER_IDENT
value before it lets the user make a commit we should do the same check
here in git-gui. We cache the result and assume that the user won't
do something which would change the status of GIT_COMMITTER_IDENT while
we are running.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I was starting to find it annoying that once you entered the 'Amend Last'
mode there was no way to go back to the 'New Commit' mode without quitting
and restarting git-gui. Its just confusing for the end-user.
Now we can flip back and forth between a new commit and an amend commit
through a pair of radio buttons on the header of the commit buffer area
and through a pair of radio menu buttons in the Commit menu.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we immediately start a rescan operation, but do so slightly
delayed (by 1 ms, to let the UI show before we start forking off
git processes), we can't let the user try to activate any of the
restricted GUI commands before the 1 ms timer expires and we kick
off the rescan.
So now we lock the index before we enter the Tk event loop, ensuring
that it is impossible for the user to inject a conflicting UI event
before our rescan can begin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the user selects a number of files they would typically expect
to be able to act on that selection, such as by including those files
into the next commit.
So we now have a menu option under the Commit menu that lets the user
include only the selection, rather than everything. If there is no
selection but there is a file in the diff viewer than we consider that
to be the selection (a selection of 1). Unfortunately we don't disable
this option yet when there's nothing selected to include, but this is
probably not a big deal as there are very few situations where there
are no selected files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It just felt wrong to me that I was using _ as part of the mode argument
to display_file to mean "don't care/use existing" and * as part of
the mode argument to mean "force to _".
So instead use ? to mean "don't care/use existing" and _ to mean
"force to _". The code is a lot clearer this way and hopefully it
won't drive another developer insane, as it did me.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I noticed that we were reshowing the current diff during a commit;
this occurs because we feed every added and modified file through
update-index just before commit. During the update-index process
we reshow the current diff if the current file in the diff pane
was one of those added or modified files we reprocessed. This
just slows down the UI more than is necessary.
So refactoring update_index so that we don't call reshow_diff
from within that code; instead we do it at a higher level.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently I never really tested the logic for making or amending an
initial commit, so although most of the code was here in git-gui it
didn't quite work as it was intended to.
So this is all just bug fixes to make initial commits correctly
generate the list of files going into the initial commit, or to
show a newly added file's diff, and to amend an initial commit.
Because we really want to diff the index against a tree-ish and
there is no such tree-ish on an initial commit we create an empty
tree through git-mktree and diff against that. This unfortunately
creates a dangling tree, which may confuse a new user who uses
git-gui to make a new commit and then immediately afterwards runs
git fsck-objects to see if their object database is corrupt or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we can't locate a .git directory for the given directory we need to
show a message to the user to let them know the directory wasn't found.
But since this is before we have shown our main application window we
cannot use that as the parent for the error popup; on Mac OS X this
causes an error and prevents the dialog from showing.
Instead only add -parent . to the popup call if we have mapped (shown)
the main window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a user works with a repository frequently they may want to just
create an icon they can use to launch git-gui against that repository.
Since we already support this concept on Windows we can do the same on
Mac OS X by creating a .app file with a tiny shell script in it that
sets up the necessary environment then invokes our script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Don't offer to fetch from a remote unless we have at least one Pull:
line in its .git/remotes/<name> file or at least one configuration
value for remote.<name>.fetch. Ditto for push.
Users shouldn't be fetching or pushing branch groups unless they
have them configured; anything else is just crazy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we have some serious problems with the GIT_DIR environment variable
on Windows we cannot let the user use a non-standard GIT_DIR with their
working directory.
So require that the GIT_DIR name is actually ".git", that it exists,
and that its parent directory is our working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are running on Windows we now offer a 'Create Desktop Icon' menu
item under the Project menu. This pops up a save dialog box letting
the user create a .bat file on their desktop (or somewhere else). The
.bat script will startup Cygwin with a login shell then launch git-gui
in the current working directory.
This is very useful for Windows users who have little to no desire to
start a command window just to run a git-gui session.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some users may want to start us by running "git --git-dir=... gui"
rather than trying to cd into the directory first. This is especially
true if they want to just make a shortcut to our executable on Windows
and always have that associated with a certain repository.
Since Tcl on Windows throws away our environment and doesn't pass it
down to the child process correctly we cannot call git-rev-parse to
get the GIT_DIR environment variable. So instead we ask for it
specifically ourselves; if its not defined then we ask rev-parse.
This should actually reduce startup by 1 fork/exec if we were started
as "git gui" as GIT_DIR will be set for us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we want to be installed in gitexecdir so that "git gui" works we
can guess where that directory is by asking the git wrapper executable
and locating ourselves at the same location using the same install
rules as core git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is no reason why the user should be able to operate on the diff
buffer if there is no currently selected diff; likewise the "File:"
label text appears rather silly looking all by itself when no diff
is being shown in the diff buffer.
So now we only enable widgets (like menu items) if there is a diff
currently showing, and we disable them when a diff isn't showing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has "Allow Partially Included Files" disabled (and most
probably will as its the default setting) we should run update-index
on every included file before commit to make sure that any changes
made by the user since the last rescan will still be part of this
commit.
If we don't update-index every modified file the user will likely
become confused when part of their changes were committed and other
parts weren't; and those other parts won't show up until a later
rescan occurs. Since we don't rescan immediately after a commit
this may be a while.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like rescan we also have cases where we need to perform a script
after we have finished updating a number of files in the index. By
changing the parameter structure of update_index we can easily pass
through any script we need to run afterwards, such as picking up
in the middle of a commit, or finishing what is left of a rescan.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There are some situations where we need to run rescan and have it do
more than just updating the status in the UI when its complete. To
help with that this changes the rescan procedure to take a script which
it will run at the global level as soon as the rescan is done and the
UI has finished updating with the results. This is useful for example
if we performed a rescan as part of a commit operation; we can go back
to the commit where we left off when the rescan got initiated.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we refer to the act of updating our memory structures with index
and working directory differences as a rescan in the UI its probably
a good idea to make the related procedures have the same name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because I want to let users apply actions to more than one file at
a time we really needed a concept of "the current selection" from
the two file lists.
Since I'm abusing a Tk text widget for the file displays I can't
really use the Tk selection to track which files are picked and
which aren't. So instead we keep this in an array to tell us
which paths are currently selected and we use an inverse fg/bg
for the selected file display. This is common most operating
systems as a selection indicator.
The selection works like most users would expect; single click will
clear the selection and pick only that file, M1-click (aka Ctrl-click
or Cmd-click) will toggle the one file in/out of the selection, and
Shift-click will select the range between the last clicked file and
the currently clicked file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Mac OS X the no differences informational message was linewrapped
at the wrong points due to the limited width of the system dialog,
yet the LFs embedded in the message (where I linewrapped it manually)
were also being honored. This resulted in a very difficult to read
paragraph of text.
So this narrows the text down by another 10 columns or so, making it
more readable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm not a huge fan of putting the left and right mouse actions into
the same procedure. Originally this is how Paul had implemented the
logic in gitool and I had carried some of that over into git-gui, but
now that I'm getting ready to implement right mouse click features to
act on files I really should split this apart.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The concept of the Git index is confusing for many users, especially
those who are newer to Git.
Since git-gui is (at least partially) intended to be used by newer
users who don't need the complexity of the index to be put in front
of them early on, we should hide it by making any partially included
file fully included as soon as we identify it. To do this we just
run a quick update_index pass on any file which differs both in the
index and the working directory, as these files have already been
at least partially included by the user.
A new option has been added in the options dialog (gui.partialinclude)
which lets the user enable accessing the index from git-gui. This
just disables the automatic update_index pass on partially included
files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
So although a text field with a flat relief looks like a label on
Windows it doesn't on Mac OS X. The Aqua version of Tk is still
drawing a border around the text field and that makes the diff pane
header look pretty ugly.
Earlier I had made the file name area into a text widget so the user
could highlight parts of it and copy them onto the clipboard; but with
the context menu being present this isn't quite as necessary as the user
can copy the file name to the clipboard using that instead. So although
this is a small loss in functionality for non-Mac OS X systems I think it
is still reasonable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Moved the Close button over to the lower right corner where our
Cancel/Save buttons are in the options dialog. This should fit
better with our own look and feel as well as that of most apps
on Mac OS X and Windows.
Also set the lower status bar in a console window to indicate the
process is working and that the user should wait for it to finish.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because the Tk pack layout manager gives all space to the right/bottom
most widget during expand/contract of the frame we were adding and
removing all space from the status area of the bar and not from the
file name, which is what we actually wanted.
A simple enough fix is to just put the status of the given file on
the left side of the diff viewer header rather than on the right.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When I changed from 'check in' to 'include' I missed the human friendly
status displayed in the right side of the diff viewer heading. It was
still reporting 'Checked in' for a fully included file, which is not
what we wanted it to say.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There's a lot of reasons why the user might need to obtain the
complete (or just part of) path of a file which they are currently
viewing in the diff viewer pane. So now we allow selection on this
widget by using a text widget instead of a label. We also offer a
context menu which has actions for copying the selection or the entire
value onto the clipboard.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we shove a large number of files at update-index and they have
very short path names we are likely going to fit a large number of
them into the pipe buffer very early; thereby seeing a huge progress
update followed by lots of waiting between progress updates due to
the latency of update-index.
Using a smaller buffer should help smooth out the progress updates
as we are better able to keep tabs on the update-index process'
progress through our list of paths.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its a little surprising to see the UI update the icons for files
in random order, due to the fact that the files are updating in
the order they appear within the array (which is based on a hash
function and not order). So sort the list of files before we send
any to update-index so the order of operation is means something to
the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When displaying a diff the Git default of 3 line of context may not be
enough for a user to see what has actually changed. Consequently we
set our own program default to 5 lines of context and then allow the
user to adjust this on a per-repository and global level through our
options dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'd like to allow the user to have more control over how we format
the diff in the diff viewer; to that end we need to add additional
options to the diff-index command line as we construct the command
for execution.
So cleanup the command handling code now to use lappend so we can
come back and add in our additional options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We can't ask the diff viewer to recompute the diff until after our
update-index child process terminates, as the diff programs need to
be able to read the updated index in order to generate the correct
diff. This is actually why we prevent diffs from being generated
while there is an update lock on the index, which is why we ignored
our own show_diff invocation in the middle of the write_update_index
event handler.
So now we mark a flag if we identify that the file currently in the
diff viewer was also sent to update-index; then later when the
update-index process has terminated we update the diff viewer if
the flag is true.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is one of those stupid Tcl mistakes that an experienced Tcl
programmer just wouldn't make. We should always use eq and ne to
compare string values (and never == or !=) as when we use ==/!=
Tcl will attempt to convert either side to numeric if one of the
two sides looks like a numeric. This could cause some trouble if
a file named "1" exists and a different file named "1.0" also exists;
their paths are equal according to == but not according to eq.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git-commit.sh invokes hooks/post-commit after running git rerere
we should do the same if its available and executable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We were originally trying to use $commit_active to tell us if there was
a commit currently in progress, just so we didn't attempt to start a
second (parallel) one by mistake. But really the index lock handles
this for us as it won't let us lock the index if it is already locked
for update. So this can't happen.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I started to notice on Windows that commits took a lot longer to get
going than on my Mac OS X system. The real reason is the repositories
that I'm testing with on Windows all enabled the standard pre-commit hook
while my test repository on Mac OS X doesn't have it executable (so its
not running). So the Windows repositories are spending this
lag time running that hook.
Now we run the pre-commit hook in the background, allowing the UI to
update and tell the user we are busy doing things.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because the pull diffstat summary can take as long as the pull itself
some users may just choose to disable the summary and save themselves
an extra few seconds during each pull. This is especially true if the
user really doesn't care about the other files being modified, as due
to their project organizational structure they aren't really responsible
for their content.
This adds an option to the options panel which lets the user disable
the diffstat summary (and thus we pass --no-summary to git-pull) but
there does appear to be a bug in the config saving code where we did
not set the local repo config differently from the global config.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git-repo-config will supply us a union of both the global and
the local repository configuration data when we invoke it during startup
there is no reason to go get the global configuration with an extra call
to repo-config unless the user is trying to view & edit all options in
the options dialog.
Since skipping this extra repo-config invocation save us a little bit of
time its nice to be able to avoid it when we are invoked as git-citool
and won't be running very long.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user is invoking us as git-citool then they want to perform a
single commit and exit quickly. Since we are about to be a very short
lived process we should do what we can to avoid spending CPU time setting
up menus which the user will never use, like the fetch/push/pull menus.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently Tcl is being helpful on Windows during exec and is throwing a
\ in front of every { it finds in the string. I'm guessing they think
the value might be read by another Tcl program? Anyway, Git faithfully
stores the \{ sequence and sends it back that way to Tcl, at which point
Tcl parses the list wrong and starts to break it in the middle of any
element which contains spaces. Therefore a list such as:
-family {Times New Roman}
gets broken up into the pairs:
{-family \{Times}
{New Roman}
which is very incorrect. So now we replace all { and } with "", at which
point Tcl doesn't throw \ in front of the " on the way out to Git yet it
reads it correctly as a list on the way back in.
I also found and fixed a bug in the way we restored the fonts when the
user presses Restore Defaults in the options dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The tkwait visibility command and Windows doesn't seem to realize
the window is visible, consequently we are never finishing our
initialization by calling update_status.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since the font name can only be chosen from within the options dialog
giving the user fast access to this dialog from within a context menu
that already talks about increasing and decreasing the font size may
help users to locate the font name setting as well.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Display the name of "this" repository rather than the quite ambiguous
string "This". The idea is that seeing the name of the directory the
repository is stored in should help jog the user's memory about what
they are setting options for.
Also place the options dialog immediately over the git-gui main window
when it gets opened. This way the user isn't scrolling very far away
to gain access to the window. At least on my Mac OS X system not doing
this makes the options dialog open rather far away, thus requiring lots
of mouse activity to reach it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-update-index process can take a while to process a large
number of files; for example my laptop would probably need almost
an hour to chug through 20,000 modified files. In these incredibly
large cases the user should be given at least some feedback to let
them know the application is still working on their behalf, even if
it won't them do anything else (as the index is locked).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This turned out to take a lot more time than I thought it would take;
but now users can edit the main UI font and the diff/fixed with font
by changing both the family name and/or the point size of the text.
We save the complete Tk font specification to the user's ~/.gitconfig
file upon saving options. This is probably more verbose than it needs
to be as there are many useless options recorded (e.g. -overstrike 0)
that a user won't really want to use in this application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
