I'm seeing a lot of silent failures from git-update-index on
Windows and this is leaving the index.lock file intact, which
means users are later unable to perform additional operations.
When the index is locked behind our back and we are unable to
use it we may need to allow the user to delete the index lock
and try again. However our UI state is probably not currect
as we have assumed that some changes were applied but none of
them actually did. A rescan is the easiest (in code anyway)
solution to correct our UI to show what the index really has
(or doesn't have).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git progress bars from tools like git-push and git-fetch use CR
to skip back to the start of the current line and redraw it with
an updated progress. We were doing this in our Tk widget but had
failed to skip the CR, which Tk doesn't draw well.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Post Git 1.5.3 a new style progress bar has been introduced that
uses only one line rather than two. The formatting of the completed
and total section is also slightly different so we must adjust our
regexp to match. Unfortunately both styles are in active use by
different versions of Git so we need to look for both.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-write-tree fails (such as if the index file is currently
locked and it wants to write to it) we were not getting the error
message as $tree_id was always the empty string so we shortcut
through the catch and never got the output from stderr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently native Tcl/Tk on Windows is using \ as the return value
from [file separator] but [file normalize] on that same system is
using / rather than \ to represent a directory separator. I really
think that is nuts, but its what is happening.
So we can actually just hardcode our separator to / as all systems
we support (Windows, Mac OS X, UNIX) use /.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user tries to clone a Git repository that is actually a
workdir of another repository (by way of contrib git-new-workdir)
then the contents of .git is a series of Windows .lnk files which
Tcl can't read if this is a native Tcl process. To read the real
objects directory we need to resolve the link to that location.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows its better to use a shortcut (.lnk file) over a batch
script (.bat) as we can specify the icon file for the .lnk and
thus have these git specific objects appear on the desktop with
that git specific icon file.
Unfortunately the authors of Tcl did not bless us with the APIs
needed to create shortcuts from within Tcl. But Microsoft did
give us Windows Scripting Host which allows us to execute some
JavaScript that calls some sort of COM object that can operate
on a .lnk file.
We now build both Cygwin and non-Cygwin "desktop icons" as proper
Windows .lnk files, using the "Start in" property of these files
to indicate the working directory of the repository the user wants
to launch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows we need to actually setup binds for the accelerator
keys, otherwise the OS doesn't respond to them when the user
presses the key combinations. Apparently we automatically get
these on Mac OS X when we configure the menu commands, but not
on Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Although we are using a text widget here we really do not
want the end-user to be able to modify the text it displays.
So we need to disable it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We need to remove any variable traces we may have installed
when the panel is destroyed as the trace may attempt to use
a widget that no longer exists on this panel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we show the repository chooser as the primary toplevel (".") we
now offer the major choices not just on the window as hyperlinks but
they also now are shown in the Repository menu, including the recent
repository list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Making a user click twice to select which action they want to perform
when starting git-gui is just wasting their time. Clicking once on a
radio button and then clicking again on the "Next >" button is quite
unnecessary.
Since the recent repository list is shown as a list of hyperlinks we
now offer the 3 basic startup actions as hyperlinks. Clicking on a
link will immediately jump to the next UI panel, saving the user time
as they don't need to click an additional button.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-gui is started outside a work tree the repository chooser
will offer a list of recently opened repositories. Clicking on
any list entry directly opens the repository.
The list of recently opened repositories is stored in the config
as the multi-valued option gui.recentrepo. If the list grows beyond
10 entries it will be truncated by removing one of the older entries.
Only repositories that are opened through the repository chooser
will get added to the recent list. Repositories opened from the
shell will not yet be added to the recent list, as users are likely
to have a way to easily return to the same directory via their shell.
[sp: This is actually a combined work from both Steffen and myself.
Most of the ideas are Steffen's, as is the basic outline of
the code, but any outstanding bugs are entirely my fault.]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A Mac OS X UI convention is to have Cmd-, be the accelerator key
for the preferences window, which by convention is located in the
apple menu under a separator below the about command. We also now
call this "Preferences..." as that is the conventional term used
in English.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes the Fetch menu looks really odd, such as if you are in a
repository that has no remotes configured when you start git-gui.
Here we didn't have any items to add to the Fetch menu so it was a
tad confusing for the end-user to see an empty menu on the menu bar.
We now place all of the commands related to fetching and pushing of
changes into a single "Remote" menu. This way we have a better class
of bucket that we can drop additional remote related items into such
as doing a remote merge or editing the remote configuration specs.
The shortcuts to execute fetch/remote prune/push on existing remote
specifications are now actually submenus listing the remotes by name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are updating the index to stage or unstage changes or reverting
files in the working directory we can use the progress handling parts
of our status bar to perform this display work, reducing the amount of
code duplication we have in the index handling module.
Unfortunately the status bar is still a strict approximation as it is
unable to know when git-update-index has processed the data we fed to
it. The progress bar is actually a progress of the pipe buffer filling
up in the OS, not of the actual work done. Still, it tells the user we
are working and that has some value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most applications tend to have some sort of pretty image in the
about dialog, because it spruces the screen up a little bit and
makes the user happy about reading the information shown there.
We already have a logo in the repository selection wizard so we
can easily reuse this in the about dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The about dialog is getting somewhat long in size and will probably
only get more complex as I try to improve upon its display. As the
options dialog is even more complex than the about dialog we move
the about dialog into its own module to reduce the complexity of the
option dialog module.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
By moving the logo into its own procedure we can use it in
multiple locations within the UI, but still load it only if
the logo is going to be used by the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some workflows allow the user to forcefully update a remote branch,
such as in a "proposed updates" (aka "pu") branch where the branch
is rewound and rebuilt on a daily basis against the current master
branch. In such a case the "--force" or leading + must be used to
make git-push execute anyway, even though it may be discarding one
or more commits on the remote side.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than displaying the stock red "Tk" icon in our window
title bars and on the task bar we now show a Git specific logo.
This is Henrik Nyh's logo that we also use in the startup wizard,
scaled to a 16x16 image for Windows task bar usage with a proper
transparent background.
Signed-off-by: Shawn O. Pearce <shawn.o.pearce@bankofamerica.com>
The setup wizard looks better if we layout the progress bar as
two lines: the first line holds the message text and our text
formatting of the progress while the second line holds the bar
itself. Both extend the full width of the window and we try to
pad out the message text so the window doesn't expand when the
completed progress number jumps to the next order of magnitude.
This change required updating the progress meter format string
to allow the application to supply the precision. So we also
are updating all of the translations at once to use the newer
formatting string.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Henrik came up with this alternative logo for gitweb and posted
it on his blog:
http://henrik.nyh.se/2007/06/alternative-git-logo-and-favicon
The msysGit port uses his logo within some of their components,
and frankly it looks better here in git-gui for our repository
setup wizard screen. The logo fits quite nicely along the left
edge of our window, leaving significantly more vertical space
for things like the git-fetch console output.
Because the logo changes the layout charateristics of the setup
window I also needed to adjust some of the padding for our widgets
and stop using a fixed width window size. We now let Tk compute
the correct size of the main window whenever the layout changes,
and drop the window into roughly the upper left 1/3 of the desktop
so its not quite centered but is likely to be far enough away from
any sort of task bars/menu bars/docks that the user may have along
any edge of the screen.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have added a scrollbar to the console window because one
direction has too much text to fit in the available screen space
we should just keep the scrollbars. Its annoying to watch our
horizontal scrollbar bounce in and out of the window as additional
text is inserted into the widget and the need for the scrollbar
comes and goes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the console finishes displaying its output and is "done" but
needs to draw a scrollbar to show the final output messages it
is possible for Tk to delete the window namespace before it does
the text widget updates, which means we are unable to add the
horizontal or vertical scrollbar to the window when the text
widget decides it cannot draw all glyphs on screen.
We need to delay deleting the window namespace until we know
the window is not going to ever be used again. This occurs if
we are done receiving output, the command is successful and the
window is closed, or if the window is open and the user chooses
to close the window after the command has completed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the source repository is using an objects/info/alternates file
we need to copy the file to our new repository so that it can access
any objects that won't be copied/hardlinked as they are stored in the
alternate location.
We explicitly resolve all paths in the objects/info/alternates as
relative to the source repository but then convert them into an
absolute path for the new clone. This allows the new clone to
access the exact same locaton as the source repository, even if
relative paths had been used before.
Under Cygwin we assume that Git is Cygwin based and that the paths
in objects/info/alternates must be valid Cygwin UNIX paths, so we
need to run `cygpath --unix` on each line in the alternate list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are doing a "standard" clone by way of hardlinking the
objects (or copying them if hardlinks are not available) the
UI can freeze up for a good few seconds while Tcl scans all
of the object directories. This is espeically noticed on a
Windows system when you are working off network shares and
need to wait for both the NT overheads and the network.
We now show a progress bar as we count the objects and build
our list of things to copy. This keeps the user amused and
also makes sure we run the Tk event loop often enough that
the window can still be dragged around the desktop.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we failed to create our test hardlink for the first object
we need to link/copy then the only recourse we have is to make
a copy of the objects. Users don't really need to know the OS
details about why the hardlink failed as its usually because
they are crossing filesystem boundaries.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We shouldn't create scrollbars for the horziontal or vertical sides
unless there is enough content to make it worth drawing these widgets
on screen. This way users don't loose screen space to objects that
won't help them navigate the display.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are started outside of a git repository than it is likely
the user started us from some sort of desktop shortcut icon in
the operating system. In such a case the user is expecting us to
prompt them to locate the git repository they want to work on,
or to help them make a new repository, or to clone one from an
existing location. This is a very simple wizard that offers the
user one of these three choices.
When we clone a repository we always use the name `master` in the
local repository, even if the remote side does not appear to point
to that name. I chose this as a policy decision. Much of the Git
documentation talks about `master` being the default branch in a
repository and that's what git-init does too. If the remote side
doesn't call its default branch `master` most users just don't care,
they just want to use Git the way the documentation describes.
Rather than relying on the git-clone Porcelain that ships with
git we build the new repository ourselves and then obtain content
by git-fetch. This technique simplifies the entire clone process
to roughly: `git init && git fetch && git pull`. Today we use
three passes with git-fetch; the first pass gets us the bulk of
the objects and the branches, the second pass gets us the tags,
and the final pass gets us the current value of HEAD to initialize
the default branch.
If the source repository is on the local disk we try to use a
hardlink to connect the objects into the new clone as this can
be many times faster than copying the objects or packing them and
passing the data through a pipe to index-pack. Unlike git-clone
we stick to pure Tcl [file link -hard] operation thus avoiding the
need to fork a cpio process to setup the hardlinks. If hardlinks
do not appear to be supported (e.g. filesystem doesn't allow them or
we are crossing filesystem boundaries) we use file copying instead.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The console window titles should also be marked up with i18n strings so
these can be properly localized.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes we use a Tk text widget as though it were a listbox.
This happens typically when we want to show an icon to the left
of the text label or just when a text widget is generally a better
choice then the native listbox widget.
In these cases if we want the user to have control over the selection
we implement our own "in_sel" tag that shows the selected region
and we perform our own selection management in the background
via keybindings and mouse bindings. In such uses we don't want
the user to be able to activate the native platform selection by
dragging their mouse through the text widget. Doing so creates a
very confusing display and the user is left wondering what it may
mean to have two different types of selection in the same widget.
Tk doesn't allow us to delete the "sel" tag that it uses internally
to manage the native selection but it will allow us to make it
invisible by setting the tag to have the same display properties
as unselected text. So long as we don't actually use the "sel"
tag for anything in code its effectively invisible.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tcl expression "[append [mc Foo] Bar]" does not return the string
"FooBar" after translation; instead it is setting the variable Foo to
the value Bar, or if Foo is already defined it is appending Bar onto
the end of it. This is *not* what we wanted to have happen here.
Tcl's join function is actually the correct function but its default
joinStr argument is a single space. Unfortunately all of our call
sites do not want an extra space added to their string. So we need
a small wrapper function to make the call to join with an empty
join string. In C this is (roughly) the job of the strcat function.
Since strcat is not yet used at the global level it is a reasonable
name to use here.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In 9adccb05 Matthijs Melchior changed our selection colors in the
main index/working directory file lists to use a lightgray as the
background color as this made the UI easier to read on all platforms.
When we did that change we missed doing also doing in the file
browser UI. Doing so just makes the entire thing UI consistent.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most of these changes were suggested by Shawn Pearce in an answer
to Johannes Schindelin.
Some strings for the blame module were added too.
[sp: Minor edits in blame module formatting]
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
git-gui: Paper bag fix "Commit->Revert" format arguments
git-gui: Provide 'uninstall' Makefile target to undo an installation
git-gui: Font chooser to handle a large number of font families
The recent bug fix to correctly handle filenames with %s (or any
other valid Tcl format specifier) missed a \ on this line and
caused the remaining format arguments to not be supplied when we
updated the status bar. This caused a Tcl error anytime the user
was trying to perform a file revert.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Simon Sasburg noticed that on X11 if there are more fonts than can
fit in the height of the screen Tk's native tk_optionMenu does not
offer scroll arrows to the user and it is not possible to review
all choices or to select those that are off-screen. On Mac OS X
the tk_optionMenu works properly but is awkward to navigate if the
list is long.
This is a rewrite of our font selection by providing a new modal
dialog that the user can launch from the git-gui Options panel.
The dialog offers the user a scrolling list of fonts in a pane.
An example text shows the user what the font looks like at the size
they have selected. But I have to admit the example pane is less
than ideal. For example in the case of our diff font we really
should show the user an example diff complete with our native diff
syntax coloring.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Simon Sasburg <simon.sasburg@gmail.com>
Commit is used as both verb and noun. While these happen to be
the same in some languages, they are not the same in all
languages, so disambiguate them using context-sensitive i18n.
Signed-off-by: Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Currently the Git plumbing is not localized so it does not know how
to output weekday and month names that conform to the user's locale
preferences. This doesn't fit with the rest of git-gui's UI as some
of our dates are formatted in Tcl and some are just read from the Git
plumbing so dates aren't consistently presented.
Since git-for-each-ref is presenting us formatted dates and it offers
no way to change that setting even in git 1.5.3.1 we need to first do
a parse of the text strings it produces, correct for timezones, then
reformat the timestamp using Tcl's formatting routines.
Not exactly what I wanted to do but it gets us consistently presented
date strings in areas like the blame viewer and the revision picker
mega-widget's tooltips.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Someone on #git today pointed out that the revision chooser's tooltips
are were being drawn with untranslated strings for the fixed labels we
include, such as "updated", "commit" and "remote". These strings are
now passed through mc to allow them to be localized.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If `git ls-files --others` returned us the name of a directory then
it is because Git has decided that this directory itself contains a
valid Git repository and its files shouldn't be listed as untracked
for this repository.
In such a case we should label the object as a Git repository and
not just as a directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui has a minor problem with regards to symlinks that point
to directories.
git init
mkdir realdir
ln -s realdir linkdir
git gui
Now clicking on file names in the "unstaged changes" window,
there's a problem coming from the "linkdir" symlink: git-gui
complains with
error reading "file4": illegal operation on a directory
...even though git-gui can add that same symlink to the index just
fine.
This patch fix this by adding a check.
[sp: Minor fix to use {link} instead of "link" in condition
and to only open the path if it is not a symlink.]
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
git-gui: Avoid use of libdir in Makefile
git-gui: Disable Tk send in all git-gui sessions
git-gui: lib/index.tcl: handle files with % in the filename properly
Steps to reproduce the bug:
$ mkdir repo && cd repo && git init
Initialized empty Git repository in .git/
$ touch 'foo%3Fsuite'
$ git-gui
Then click on the 'foo%3Fsuite' icon to include it in a changeset, a
popup comes with:
'Error: bad field specifier "F"'
Vincent Danjean noticed the problem and also suggested the fix, reported
through
http://bugs.debian.org/441167
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
git-gui: Properly set the state of "Stage/Unstage Hunk" action
git-gui: Fix detaching current branch during checkout
git-gui: Correct starting of git-remote to handle -w option
Conflicts:
git-gui.sh
If the user tried to detach their HEAD while keeping the working
directory on the same commit we actually did not completely do
a detach operation internally. The problem was caused by git-gui
not forcing the HEAD symbolic ref to be updated to a SHA-1 hash
when we were not switching revisions. Now we update the HEAD ref
if we aren't currently detached or the hashes don't match.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Dots in a UI string usually mean that a dialog box will
appear waiting for further input. So this patch removes
unneeded dots for actions that do not require user's
input.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The procedure [mc ...] will translate the strings through msgcat.
Strings must be enclosed in quotes, not in braces, because otherwise
xgettext cannot extract them properly, although on the Tcl side both
delimiters would work fine.
[jes: I merged the later patches to that end.]
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Earlier when I rewrote the merge implementation for git-gui I broke
it such that the conflict markers for the "theirs" side of the hunk
was using a full SHA-1 ID in hex, rather than the name of the branch
the user had merged. This was because I got paranoid and passed off
the full SHA-1 to git-merge, instead of giving it the reference name
the user saw in the merge dialog.
I'd still like to resolve the SHA-1 upfront in git-gui and always use
that value throughout the merge, but I can't do that until we have a
full implementation of git-merge written in Tcl. Until then its more
important that the conflict markers be useful to the end-user, so we
need to pass off the ref name and not the SHA-1 ID.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
cehteh on #git noticed that secondary windows such as console
windows from push/fetch/merge or the blame browser failed on ion
when we tried to open them a second time.
The issue turned out to be the fact that on ion [winfo ismapped .]
returns false if . is not visible right now because it has been
obscured by another window in the same panel. So we need to keep
track of whether or not the root window has been displayed for this
application, and once it has been we cannot ever assume that ismapped
is going to return true.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is just a small code movement to cleanup how we generate
the command line for a merge. I'm only doing it to make the
next series of changes slightly more readable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a replacement of all of the icons in our tree browser
window, as the prior icons just looked too 1980s Tk-ish. The
icons used here are actually from a KDE themed look, so they
might actually be familiar to some users of git-gui.
Aside from using more modern looking icons we now have a special
icon for executable blobs, to make them stand out from the normal
non-executable blobs. We also denote symlinks now with a different
icon, so they stand out from the other types of objects in the tree.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are started for only a blame/browser/citool run we don't
usually initialize the list of remotes, or determine which refs
are tracking branches and which are local branch heads. This is
because some of that work is relatively expensive and is usually
not going to be needed if we are started only for a blame, or to
make a single commit.
However by not loading the remote configuration we were crashing
if the user tried to open a browser for another branch through
the Repository menu, as our load_all_heads procedure was unable
to decide which refs/heads/ items were actually local heads. We
now force all remote configuration data to be loaded if we have
not done so already and we are trying to create a revision mega
widget.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Resetting a large number of files on a slow filesystem can take
considerable time, just as switching branches in such a case can
take more than two seconds. We now take advantage of the progress
meter output by read-tree and show it in the main window status
bar, just like we do during checkout (branch switch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Also, the warning message when clicking "Reset" is adapted to
the wording "Reset" rather than a confusion "Cancel commit?".
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are being asked to merge a tracking branch that comes from a
remote repository accessed by the very common SSH URL format of
"user@host:/path/to/repo" then we really don't need the username
as part of the merge message, it only clutters up the history and
makes things more confusing. So we instead clip the username part
off if the local filesystem path is absolute, as its probably not
going to be an ambiguous URL even when it is missing the username.
On the other hand we cannot clip the username off if the URL is
not absolute, because in such cases (e.g. "user@host:myrepo") the
directory that the repository path is resolved in is relative to
the user's home directory, and the username becomes important.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are merging a tracking branch we know exactly what remote URL
that branch is fetched from, and what its name is on that remote
repository. In this case we can setup a merge message that looks
just like a standard `git-pull $remote $branch` operation by filling
out FETCH_HEAD before we start git-merge, and then run git-merge just
like git-pull does.
I think the result of this behavior is that merges look a lot nicer
when the came off of local tracking branches, because they no longer
say "commit 'origin/...'" to describe the commit being merged but
instead now mention the specific repository we fetched those commits
from.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we only support merging one branch we can offer the user
a better user interface experience by allowing them to select the
revision they want to merge through our revision picking widget.
This change neatly solves the problem of locating a branch out of
a sea of 200 tracking branches, and of dealing with very long branch
names that all have a common prefix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we can we now show the last modification date of a loose ref as
part of the tooltip information shown in the revision picker. This
gives the user an indication of when was the last time that the ref
was modified locally, and may especially be of interest when looking
at a tracking branch.
If we cannot find the loose ref file than we try to fallback on the
reflog and scan it for the date of the last record. We don't start
with the reflog however as scanning it backwards from the end is not
an easy thing to do in Tcl. So I'm being lazy here and just going
through the entire file, line by line. Since that is less efficient
than a single stat system call, its our fallback strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our revision chooser mega-widget now sets up tooltips for itself so
that it displays details about a commit (or a tag and the commit
it refers to) when the user mouses over that line in the filtered
ref list. If the item is from a remote tracking branch then we also
show the remote url and what branch on that remote we fetch from, so
the user has a clear concept of where that revision data originated.
To help the merge dialog I've also added a new constructor that
makes the dialog only offer unmerged revisions (those not in HEAD),
as this allows users to avoid performing merges only to get "Already
up to date" messages back from core Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm storing the URLs of any pre-configured remote repositories
that we happen to come across so that we can later use these
URLs to show to the user in parts of the UI that might care.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are checking out the branch we are already on then there is no
need to call symbolic-ref to update the HEAD pointer to the "new"
branch name, it is already correct.
Currently this situation does not happen very often, but it can be
seen in some workflows where the user always recreates their local
branch from a remote tracking branch and more-or-less ignores what
branch he/she is on right now. As they say, ignorance is bliss.
This case will however become a tad more common when we overload
checkout_op to actually also perform all of our merges. In that
case we will likely see that the branch we want to "checkout" is
the current branch, as we are actually just merging into it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
My earlier introduction of the GITGUI_BCK file (which saves the user's
commit message buffer while they are typing it) broke the Quit function.
If the user makes a commit we delete the GITGUI_BCK file; if they then
immediately quit the application we fail to rename the GITGUI_BCK file
to GITGUI_MSG. This is because the file does not exist, but our flag
still says it does. The root cause is we did not unset the flag during
commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are trying to checkout a local branch which is matched to a
remote tracking branch, but the local branch is newer than the remote
tracking branch we actually just want to switch to the local branch.
The local branch is "Already up to date".
Unfortunately we tossed away the local branch's commit SHA-1 and kept
the remote tracking branch's SHA-1, which meant that the user lost the
local changes when we updated the working directory. At least we did
not update the local branch ref, so the user's data was still intact.
We now toss the tracking branch's SHA-1 and replace with the local
branch's SHA-1 before the checkout, ensuring that we pass of the right
tree to git-read-tree when we update the working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is actually just an underlying code improvement that has no user
visible component yet. UI improvements to actually fetch and merge via
an arbitrary remote with no tracking branches must still follow to make
this change useful for the end-user.
Our tracking branch specifications are a Tcl list of three components:
- local tracking branch name
- remote name/url
- remote branch name/tag name
This change just makes the first element optional. If it is an empty
string we will run the fetch, but have the value be saved only into the
special .git/FETCH_HEAD, where we can pick it up and use it for this one
time operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I totally missed this obvious optimization in the checkout code path.
If our current repository HEAD is actually at the commit we are moving
to, and we agreed to perform this switch earlier, then we have no files
to update in the working directory and any stale mtimes are simply not
of consequence right now. We can pretend like we ran a read-tree and
skip right into the post-read-tree work, such as updating the branch
and setting the symbolic-ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are given a merge type we don't understand in checkout_op there
is probably a bug in git-gui somewhere that allowed this unknown merge
strategy to come into this part of the code path. We currently only
recognize three merge types ('none', 'ff' and 'reset') but are going
to be supporting more in the future. Rather than keep editing this
message I'm going with a very generic "Uh, we don't do that!" type of
error.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In both the ff and reset merge_types supported by checkout_op the
result is the same if the merge base of our target commit and the
existing commit is the existing commit: its a fast-forward as the
existing commit is fully contained in the target commit.
This minor cleanup in logic will make it easier to implement a
new kind of merge_type that actually merges the two trees with a
real merge strategy, such as git-merge-recursive.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I've decided to teach checkout_op how to perform more than just a
fast-forward and reset type of merge. This way we can also do a full
recursive merge even when we are recreating an existing branch from
a remote. To help with that process I'm saving the merge-base we
computed during the ff/reset/fail decision process, in case we need
it later on when we actually start a true merge operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A few users have been seeing crashes in Tk when using the undo key
binding to undo the last few keystroke events in the commit buffer.
Unfortunately that means the user loses their commit message and
must start over from scratch when the user restarts the process.
git-gui now saves the user's commit message buffer every couple of
seconds to a temporary file under .git (specifically .git/GITGUI_BCK).
At exit time we rename this file to .git/GITGUI_MSG if there is a
message, the file exists, and it is currently synchronized with the
Tk buffer. Otherwise we do our usual routine of saving the Tk buffer
to .git/GITGUI_MSG and delete .git/GITGUI_BCK, if it exists.
During startup we favor .git/GITGUI_BCK over .git/GITGUI_MSG. This
way a crash doesn't take out the user's message buffer but instead
will cause the user to lose only a few keystrokes. Most people do
not type more than 200 WPM, and with 30 possible saves per minute
we are unlikely to lose more than 7 words.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm working on refactoring the UI of the merge dialog, because as it
currently stands the dialog is absolutely horrible, especially when
you have 200+ branches available from a single remote system.
In that refactoring I plan on using the choose_rev widget to allow
the user to select exactly which branch/commit they want to merge.
However since that only selects a single commit I'm first removing
the code that supports octopus merges.
A brief consultation on #git tonight seemed to indicate that the
octopus merge strategy is not as useful as originally thought when
it was invented, and that most people don't commonly use them. So
making users fall back to the command line to create an octopus is
actually maybe a good idea here, as they might think twice before
they use it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we haven't yet loaded any commit information for a given line but
our tooltip timer fired and tried to draw the tooltip we shouldn't;
there is nothing to show.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a essentially a copy of Paul Mackerras encoding support from
gitk. I stole the code from gitk commit fd8ccbec4f, as Paul has
already done all of the hard work setting up this translation table.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I've found that the class code makes it a whole lot easier to create
more complex GUI code, especially the dialogs. So before I make any
major improvements to the merge dialog's interface I'm going to first
switch it to use the class system, so the code is slightly cleaner.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Showing only five lines of heads/tags is not very useful to a user
when they have about 10 branches that match the filter expression.
The list is just too short to really be able to read easily, at
least not without scrolling up and down. Expanding the list out
to 10 really makes the revision picker easier to read and access,
as you can read the matching branches much more quickly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now allow users to pick which commit they want to browse through
our revision picking mega-widget. This opens up in a dialog first,
and then opens a tree browser for that selected commit. It is a very
simple approach and requires minimal code changes.
I also clarified the language a bit in the Repository menu, to show
that these actions will access files. Just in case a user is not
quite sure what specific action they are looking for, but they know
they want some sort of file thing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like our blame subcommand the browser subcommand now accepts both
a revision and a path, just a revision or just a path. This way
the user can start the subcommand on any branch, or on any subtree.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm moving the code related to looking to see if we should GC now
into a procedure closer to where it belongs, the database module.
This reduces our script by a few lines for the single commit case
(aka citool). But really it just is to help organize the code.
We now perform the check after we have been running for at least
1 second. This way the main window has time to open up and our
dialog (if we open it) will attach to the main window, instead of
floating out in no-mans-land like it did before on Mac OS X.
I had to use a wait of a full second here as a wait of 1 millisecond
made our console install itself into the main window. Apparently we
had a race condition with the console code where both the console and
the main window thought they were the main window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have more than our desired number of objects and we try to
open the "Do you want to repack now?" dialog we cannot include a
-parent . argument if the main window has not been mapped yet.
On Mac OS X it appears this window isn't mapped right away, so we
had better hang avoid including it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows (which includes Cygwin) Tcl defaults to leaving the EOF
character of input file streams set to the ASCII EOF character, but
if that character were to appear in the data stream then Tcl will
close the channel early. So we have to disable eofchar on Windows.
Since the default is disabled on all platforms except Windows, we
can just disable it everywhere to prevent any sort of read problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This cat-file was done on maint, where we did not have git_read
available to us. But here on master we do, so we should make
use of it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
From Johannes Sixt <J.Sixt@eudaptics.com>:
> It seems that MSYS's wish does some quoting for Bourne shells,
> in particular, escape the first '{' of the "^{tree}" suffix, but
> then it uses cmd.exe to run "git rev-parse". However, cmd.exe does
> not remove the backslash, so that the resulting rev expression
> ends up in git's guts as unrecognizable garbage: rev-parse fails,
> and git-gui hickups in a way that it must be restarted.
Johannes originally submitted a patch to this section of commit.tcl
to use `git rev-parse $PARENT:`, but not all versions of Git will
accept that format. So I'm just taking the really simple approach
here of scanning the first line of the commit to grab its tree.
About the same cost, but works everywhere.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we are trying to execute /bin/sh we know it must be a real
Windows executable and thus ends with the standard .exe suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We cannot execute the git directory, it is not a valid Tcl command
name. Instead we just want to pass it as an argument to our sq
proc.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we get more than 80 characters of text in a single line odds
are it is output from git-fetch or git-push and its showing a
lot of detail off to the right edge that is not so important to
the average user. We still want to make sure we show everything
we need, but we can get away with that information being off to
the side with a horizontal scrollbar.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our file browser was showing bad output as it did not properly buffer
a partial record when read from `ls-tree -z`. This did not show up on
my Mac OS X system as most trees are small, the pipe buffers generally
big and `ls-tree -z` was generally fast enough that all data was ready
before Tcl started to read. However on my Cygwin system one of my
production repositories had a large enough tree and packfile that it
took a couple of pipe buffers for `ls-tree -z` to complete its dump.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now embed any GIT_* and SSH_* environment variables as well as
the path to the git wrapper executable into the Mac OS X .app file.
This should allow us to restore the environment properly when
we restart.
We also try to use proper Bourne shell single quoting when we can,
as this avoids any sort of problems that might occur due to a path
containing shell metacharacters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
