summaryrefslogtreecommitdiff
path: root/lib/choose_repository.tcl
AgeCommit message (Collapse)AuthorFilesLines
2007-10-12git-gui: Collapse $env(HOME) to ~/ in recent repositories on WindowsLibravatar Shawn O. Pearce1-2/+6
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>
2007-10-12git-gui: Support cloning Cygwin based work-dirsLibravatar Shawn O. Pearce1-7/+37
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>
2007-10-12git-gui: Bind n/c/o accelerators in repository chooserLibravatar Shawn O. Pearce1-0/+6
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>
2007-10-12git-gui: Disable the text widget in the repository chooserLibravatar Shawn O. Pearce1-0/+2
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>
2007-10-12git-gui: Fix bind errors when switching repository chooser panelsLibravatar Shawn O. Pearce1-0/+6
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>
2007-10-12git-gui: Offer repository management features in menu barLibravatar Shawn O. Pearce1-6/+49
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>
2007-10-12git-gui: Change repository browser radio buttons to hyperlinksLibravatar Shawn O. Pearce1-27/+34
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>
2007-10-12git-gui: offer a list of recent repositories on startupLibravatar Steffen Prohaska1-0/+82
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>
2007-10-10git-gui: Refactor Henrik Nyh's logo into its own procedureLibravatar Shawn O. Pearce1-38/+1
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>
2007-09-26git-gui: Make the status bar easier to read in the setup wizardLibravatar Shawn O. Pearce1-2/+2
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>
2007-09-26git-gui: Switch the git-gui logo to Henrik Nyh's logoLibravatar Shawn O. Pearce1-22/+41
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>
2007-09-24git-gui: Copy objects/info/alternates during standard cloneLibravatar Shawn O. Pearce1-0/+26
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>
2007-09-24git-gui: Keep the UI responsive while counting objects in cloneLibravatar Shawn O. Pearce1-5/+25
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>
2007-09-24git-gui: Don't bother showing OS error message about hardlinksLibravatar Shawn O. Pearce1-4/+1
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>
2007-09-23git-gui: Deiconify startup wizard so it raises to the topLibravatar Johannes Schindelin1-0/+1
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-23git-gui: Allow users to choose/create/clone a repositoryLibravatar Shawn O. Pearce1-0/+838
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>