| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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>
|
Shawn O. Pearce
Johannes Schindelin