Rather shrink the input field for "Create New Repository" and "Open
Existing Repository" as it's already done for "Clone Existing
Repository".
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The user might need to see the key before cloning a repository.
This patch makes the relevant menu item available in the Select
Repository/Clone dialog.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Before, the input boxes would not be sunken and would have larger border,
which is inconsistent with the rest of the inputboxes for repository
locations in the git-gui UI.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Instead, 'Location' is used to label such inputs; in the Clone dialog,
'Source' and 'Target' are also introduced to further clarify the situation.
The intent is to increase GUI consistency in the case location templates
(upcoming) are used - then, other locators than URL may be used.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In git-gui after clicking either on 'Create New Repository' or
'Open Existing Repository' the form elements aren't centered like
they are pretty much everywhere else in the app. At least when ran
on a mac, haven't checked on other platforms.
Using grid instead of pack seems to fix this.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Peter Karlsson pointed out there is no value in translating the
string "Apple", as this is used as the dummy label for the Apple
menu on Mac OS X systems.
The Apple menu is actually not the menu with the Apple corporate
logo, but the menu next to it, which shows the name of the
application and is typically called the application menu. Most users
of git-gui see this menu titled as "Git Gui". The actual label of
this menu comes from our Info.plist file and cannot be specified
by any other means. Translating this string in the Tcl PO files
is not necessary.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When selecting a local working directory for a new repository or a
location to clone an existing repository into we now set the insert
point at the end of the selected path, allowing the user to type in
any additional parts of the path if they so desire.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Often users setup a few source files and get a project rolling
before they create a Git repository for it. In such cases the
core Git tools allow users to initialize a new repository by
simply running `git init` at the desired root level directory.
We need to allow the same situation in git-gui; if the user is
trying to make a new repository we should let them do that to any
location they chose. If the directory already exists and already
has files contained within it we still should allow the user to
create a repository there. However we still need to disallow
creating a repository on top of an existing repository.
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 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>
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>
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 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>
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>
