development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-10-31 01:43:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
git/git-gui/lib/choose_repository.tcl

1125 lines
26 KiB
Tcl
Raw Normal View History

git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
# git-gui Git repository chooser
# Copyright (C) 2007 Shawn Pearce
class choose_repository {
field top
field w
field w_body ; # Widget holding the center content
field w_next ; # Next button
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
field w_quit ; # Quit button
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
field o_cons ; # Console object (if active)
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
# Status mega-widget instance during _do_clone2 (used by _copy_files and
# _link_files). Widget is destroyed before _do_clone2 calls
# _do_clone_checkout
field o_status
# Operation displayed by status mega-widget during _do_clone_checkout =>
# _readtree_wait => _postcheckout_wait => _do_clone_submodules =>
# _do_validate_submodule_cloning. The status mega-widget is a different
# instance than that stored in $o_status in earlier operations.
field o_status_op
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
field w_types ; # List of type buttons in clone
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
field w_recentlist ; # Listbox containing recent repositories
git-gui: Focus insertion point at end of strings in repository chooser 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>
2008-02-11 05:53:52 +00:00
field w_localpath ; # Entry widget bound to local_path
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
field done 0 ; # Finished picking the repository?
field local_path {} ; # Where this repository is locally
field origin_url {} ; # Where we are cloning from
field origin_name origin ; # What we shall call 'origin'
field clone_type hardlink ; # Type of clone to construct
git-gui: Add a 'recursive' checkbox in the clone menu. Permit to do a 'git clone --recursive' through git-gui. Add a 'recursive' checkbox in the clone menu which allows users to clone a repository and all its submodules in one go (unless the 'update' flag is set to "none" in the .gitmodules file for a submodule, in that case that specific submodule is not cloned automatically). Enable this new option per default, as most users want to clone all submodules too when cloning the superproject (This is currently not possible without leaving git gui or adding a custom tool entry for that). Signed-off-by: Henri GEIST <geist.henri@laposte.net> Thanks-to: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-03-11 18:21:01 +00:00
field recursive true ; # Recursive cloning flag
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
field readtree_err ; # Error output from read-tree (if any)
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
field sorted_recent ; # recent repositories (sorted)
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
constructor pick {} {
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
global M1T M1B use_ttk NS
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
git-gui: added gui.maxrecentrepo to extend the number of remembered repos The list of recently opened repositories shown when launching git-gui from outside a repository was hard coded to only show a maximum of 10 items. This config variable allows the user to override this default. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2013-07-10 12:31:13 +00:00
if {[set maxrecent [get_config gui.maxrecentrepo]] eq {}} {
set maxrecent 10
}
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
make_dialog top w
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
wm title $top [mc "Git Gui"]
if {$top eq {.}} {
menu $w.mbar -tearoff 0
$top configure -menu $w.mbar
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
set m_repo $w.mbar.repository
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
$w.mbar add cascade \
-label [mc Repository] \
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
-menu $m_repo
menu $m_repo
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
if {[is_MacOSX]} {
git-gui: Don't translate the special Apple menu 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>
2008-03-15 05:11:08 +00:00
$w.mbar add cascade -label Apple -menu .mbar.apple
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
menu $w.mbar.apple
$w.mbar.apple add command \
-label [mc "About %s" [appname]] \
-command do_about
git-gui: Add the Show SSH Key item to the clone dialog. 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>
2008-11-09 15:51:16 +00:00
$w.mbar.apple add command \
-label [mc "Show SSH Key"] \
-command do_ssh_key
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
} else {
$w.mbar add cascade -label [mc Help] -menu $w.mbar.help
menu $w.mbar.help
$w.mbar.help add command \
-label [mc "About %s" [appname]] \
-command do_about
git-gui: Add the Show SSH Key item to the clone dialog. 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>
2008-11-09 15:51:16 +00:00
$w.mbar.help add command \
-label [mc "Show SSH Key"] \
-command do_ssh_key
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
wm protocol $top WM_DELETE_WINDOW exit
bind $top <$M1B-q> exit
bind $top <$M1B-Q> exit
bind $top <Key-Escape> exit
} else {
wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
bind $top <Key-Escape> [list destroy $top]
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
set m_repo {}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
git-gui: Refactor Henrik Nyh's logo into its own procedure 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-10-05 12:35:41 +00:00
pack [git_logo $w.git_logo] -side left -fill y -padx 10 -pady 10
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set w_body $w.body
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
set opts $w_body.options
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w_body
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
text $opts \
-cursor $::cursor_ptr \
-relief flat \
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
-background [get_bg_color $w_body] \
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
-wrap none \
-spacing1 5 \
-width 50 \
-height 3
pack $opts -anchor w -fill x
$opts tag conf link_new -foreground blue -underline 1
$opts tag bind link_new <1> [cb _next new]
$opts insert end [mc "Create New Repository"] link_new
$opts insert end "\n"
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
if {$m_repo ne {}} {
$m_repo add command \
-command [cb _next new] \
-accelerator $M1T-N \
-label [mc "New..."]
git-gui: Bind n/c/o accelerators in repository chooser 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-12 15:13:58 +00:00
bind $top <$M1B-n> [cb _next new]
bind $top <$M1B-N> [cb _next new]
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
}
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
$opts tag conf link_clone -foreground blue -underline 1
$opts tag bind link_clone <1> [cb _next clone]
$opts insert end [mc "Clone Existing Repository"] link_clone
$opts insert end "\n"
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
if {$m_repo ne {}} {
git-gui: Avoid using the <<Copy>> binding as a menu accelerator on win32 On Windows the Control-C binding is used to copy and is mapped to the Tk virtual event <<Copy>>. In the initial git-gui dialog this is also bound as an accelerator for the Clone menu item. The effect is that both bindings run, copying the text but resetting the clone page or switching to the clone page when the user tries to copy text from one of the entry fields. This patch avoids this by using Control-L instead for Windows only. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2010-03-08 12:43:27 +00:00
if {[tk windowingsystem] eq "win32"} {
set key L
} else {
set key C
}
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
$m_repo add command \
-command [cb _next clone] \
git-gui: Avoid using the <<Copy>> binding as a menu accelerator on win32 On Windows the Control-C binding is used to copy and is mapped to the Tk virtual event <<Copy>>. In the initial git-gui dialog this is also bound as an accelerator for the Clone menu item. The effect is that both bindings run, copying the text but resetting the clone page or switching to the clone page when the user tries to copy text from one of the entry fields. This patch avoids this by using Control-L instead for Windows only. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2010-03-08 12:43:27 +00:00
-accelerator $M1T-$key \
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
-label [mc "Clone..."]
git-gui: Avoid using the <<Copy>> binding as a menu accelerator on win32 On Windows the Control-C binding is used to copy and is mapped to the Tk virtual event <<Copy>>. In the initial git-gui dialog this is also bound as an accelerator for the Clone menu item. The effect is that both bindings run, copying the text but resetting the clone page or switching to the clone page when the user tries to copy text from one of the entry fields. This patch avoids this by using Control-L instead for Windows only. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2010-03-08 12:43:27 +00:00
bind $top <$M1B-[string tolower $key]> [cb _next clone]
bind $top <$M1B-[string toupper $key]> [cb _next clone]
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
}
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
$opts tag conf link_open -foreground blue -underline 1
$opts tag bind link_open <1> [cb _next open]
$opts insert end [mc "Open Existing Repository"] link_open
$opts insert end "\n"
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
if {$m_repo ne {}} {
$m_repo add command \
-command [cb _next open] \
-accelerator $M1T-O \
-label [mc "Open..."]
git-gui: Bind n/c/o accelerators in repository chooser 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-12 15:13:58 +00:00
bind $top <$M1B-o> [cb _next open]
bind $top <$M1B-O> [cb _next open]
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
}
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
git-gui: Disable the text widget in the repository chooser 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-12 15:04:20 +00:00
$opts conf -state disabled
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
set sorted_recent [_get_recentrepos]
if {[llength $sorted_recent] > 0} {
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
if {$m_repo ne {}} {
$m_repo add separator
$m_repo add command \
-state disabled \
-label [mc "Recent Repositories"]
}
git gui: allow for a long recentrepo list The gui.recentrepo list may be longer than the maxrecent setting. Allow extra space to show any extra entries. In an ideal world, the git gui would limit the number of entries to the maxrecent setting, however the recentrepo config list may have been extended outwith the gui, or the maxrecent setting changed to a reduced value. Further, when testing the gui's recentrepo logic it is useful to show these extra, but valid, entries. Signed-off-by: Philip Oakley <philipoakley@iee.org>
2015-12-14 12:56:40 +00:00
if {[set lenrecent [llength $sorted_recent]] < $maxrecent} {
set lenrecent $maxrecent
}
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::label $w_body.space
${NS}::label $w_body.recentlabel \
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
-anchor w \
-text [mc "Open Recent Repository:"]
set w_recentlist $w_body.recentlist
text $w_recentlist \
-cursor $::cursor_ptr \
-relief flat \
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
-background [get_bg_color $w_body.recentlabel] \
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
-wrap none \
-width 50 \
git gui: allow for a long recentrepo list The gui.recentrepo list may be longer than the maxrecent setting. Allow extra space to show any extra entries. In an ideal world, the git gui would limit the number of entries to the maxrecent setting, however the recentrepo config list may have been extended outwith the gui, or the maxrecent setting changed to a reduced value. Further, when testing the gui's recentrepo logic it is useful to show these extra, but valid, entries. Signed-off-by: Philip Oakley <philipoakley@iee.org>
2015-12-14 12:56:40 +00:00
-height $lenrecent
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
$w_recentlist tag conf link \
-foreground blue \
-underline 1
git-gui: Collapse $env(HOME) to ~/ in recent repositories on Windows 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-12 20:33:45 +00:00
set home $::env(HOME)
set home "[file normalize $home]/"
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
set hlen [string length $home]
foreach p $sorted_recent {
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
set path $p
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
if {[string equal -length $hlen $home $p]} {
git-gui: Collapse $env(HOME) to ~/ in recent repositories on Windows 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-12 20:33:45 +00:00
set p "~/[string range $p $hlen end]"
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
}
regsub -all "\n" $p "\\n" p
$w_recentlist insert end $p link
$w_recentlist insert end "\n"
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
if {$m_repo ne {}} {
$m_repo add command \
-command [cb _open_recent_path $path] \
-label " $p"
}
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
}
$w_recentlist conf -state disabled
$w_recentlist tag bind link <1> [cb _open_recent %x,%y]
pack $w_body.space -anchor w -fill x
pack $w_body.recentlabel -anchor w -fill x
pack $w_recentlist -anchor w -fill x
}
git-gui: Switch the git-gui logo to Henrik Nyh's logo 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-26 18:59:09 +00:00
pack $w_body -fill x -padx 10 -pady 10
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w.buttons
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set w_next $w.buttons.next
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
set w_quit $w.buttons.quit
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::button $w_quit \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Quit"] \
-command exit
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
pack $w_quit -side right -padx 5
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
pack $w.buttons -side bottom -fill x -padx 10 -pady 10
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
if {$m_repo ne {}} {
$m_repo add separator
$m_repo add command \
-label [mc Quit] \
-command exit \
-accelerator $M1T-Q
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
bind $top <Return> [cb _invoke_next]
bind $top <Visibility> "
git-gui: Switch the git-gui logo to Henrik Nyh's logo 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-26 18:59:09 +00:00
[cb _center]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
grab $top
focus $top
git-gui: Switch the git-gui logo to Henrik Nyh's logo 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-26 18:59:09 +00:00
bind $top <Visibility> {}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
"
git-gui: Deiconify startup wizard so it raises to the top Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-24 02:29:18 +00:00
wm deiconify $top
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
tkwait variable @done
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
grab release $top
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
if {$top eq {.}} {
eval destroy [winfo children $top]
}
}
git-gui: Switch the git-gui logo to Henrik Nyh's logo 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-26 18:59:09 +00:00
method _center {} {
set nx [winfo reqwidth $top]
set ny [winfo reqheight $top]
set rx [expr {([winfo screenwidth $top] - $nx) / 3}]
set ry [expr {([winfo screenheight $top] - $ny) / 3}]
wm geometry $top [format {+%d+%d} $rx $ry]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
method _invoke_next {} {
if {[winfo exists $w_next]} {
uplevel #0 [$w_next cget -command]
}
}
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
proc _get_recentrepos {} {
set recent [list]
git gui: cope with duplicates in _get_recentrepo _get_recentrepo will fail if duplicate invalid entries are present in the recentrepo config list. The previous commit fixed the 'git config' limitations in _unset_recentrepo by unsetting all config entries, however this code would fail on the second attempt to unset it. Refactor the code to pre-sort and de-duplicate the recentrepo list to avoid a potential second unset attempt. Signed-off-by: Philip Oakley <philipoakley@iee.org>
2015-12-14 11:19:32 +00:00
foreach p [lsort -unique [get_config gui.recentrepo]] {
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
if {[_is_git [file join $p .git]]} {
lappend recent $p
git-gui: Keep repo_config(gui.recentrepos) and .gitconfig in sync When the number of recent repo's gets to ten there can be a situation where an item is removed from the .gitconfig file via a call to git config --unset, but the internal representation of that file (repo_config(gui.recentrepo)) is not updated. Then a subsequent attempt to remove an item from the list fails because git-gui attempts to call --unset on a value that has already been removed. This leads to duplicates in the .gitconfig file, which then also cause errors if the git-gui tries to --unset them (rather than using --unset-all. --unset-all is not used because it is not expected that duplicates should ever be allowed to exist.) When loading the list of recent repositories (proc _get_recentrepos) if a repo in the list is not considered a valid git reposoitory then we should go ahead and remove it so it doesn't take up a slot in the list (since we limit to 10 items). This will prevent a bunch of invalid entries in the list (which are not shown) from making valid entries dissapear off the list even when there are less than ten valid entries. See: http://code.google.com/p/msysgit/issues/detail?id=362 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-23 22:37:17 +00:00
} else {
_unset_recentrepo $p
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
}
}
git gui: cope with duplicates in _get_recentrepo _get_recentrepo will fail if duplicate invalid entries are present in the recentrepo config list. The previous commit fixed the 'git config' limitations in _unset_recentrepo by unsetting all config entries, however this code would fail on the second attempt to unset it. Refactor the code to pre-sort and de-duplicate the recentrepo list to avoid a potential second unset attempt. Signed-off-by: Philip Oakley <philipoakley@iee.org>
2015-12-14 11:19:32 +00:00
return $recent
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
}
proc _unset_recentrepo {p} {
regsub -all -- {([()\[\]{}\.^$+*?\\])} $p {\\\1} p
git gui: de-dup selected repo from recentrepo history When the gui/user selects a repo for display, that repo is brought to the end of the recentrepo config list. The logic can fail if there are duplicate old entries for the repo (you cannot unset a single config entry when duplicates are present). Similarly, the maxrecentrepo logic could fail if older duplicate entries are present. The first commit of this series ({this}~2) fixed the config unsetting issue. Rather than manipulating a local copy of the $recent list (one cannot know how many entries were removed), simply re-read it. We must also catch the error when the attempt to remove the second copy from the re-read list is performed. Signed-off-by: Philip Oakley <philipoakley@iee.org>
2015-12-14 10:42:04 +00:00
catch {git config --global --unset-all gui.recentrepo "^$p\$"}
git-gui: Keep repo_config(gui.recentrepos) and .gitconfig in sync When the number of recent repo's gets to ten there can be a situation where an item is removed from the .gitconfig file via a call to git config --unset, but the internal representation of that file (repo_config(gui.recentrepo)) is not updated. Then a subsequent attempt to remove an item from the list fails because git-gui attempts to call --unset on a value that has already been removed. This leads to duplicates in the .gitconfig file, which then also cause errors if the git-gui tries to --unset them (rather than using --unset-all. --unset-all is not used because it is not expected that duplicates should ever be allowed to exist.) When loading the list of recent repositories (proc _get_recentrepos) if a repo in the list is not considered a valid git reposoitory then we should go ahead and remove it so it doesn't take up a slot in the list (since we limit to 10 items). This will prevent a bunch of invalid entries in the list (which are not shown) from making valid entries dissapear off the list even when there are less than ten valid entries. See: http://code.google.com/p/msysgit/issues/detail?id=362 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-23 22:37:17 +00:00
load_config 1
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
}
proc _append_recentrepos {path} {
set path [file normalize $path]
set recent [get_config gui.recentrepo]
if {[lindex $recent end] eq $path} {
return
}
set i [lsearch $recent $path]
if {$i >= 0} {
_unset_recentrepo $path
}
git config --global --add gui.recentrepo $path
git-gui: Keep repo_config(gui.recentrepos) and .gitconfig in sync When the number of recent repo's gets to ten there can be a situation where an item is removed from the .gitconfig file via a call to git config --unset, but the internal representation of that file (repo_config(gui.recentrepo)) is not updated. Then a subsequent attempt to remove an item from the list fails because git-gui attempts to call --unset on a value that has already been removed. This leads to duplicates in the .gitconfig file, which then also cause errors if the git-gui tries to --unset them (rather than using --unset-all. --unset-all is not used because it is not expected that duplicates should ever be allowed to exist.) When loading the list of recent repositories (proc _get_recentrepos) if a repo in the list is not considered a valid git reposoitory then we should go ahead and remove it so it doesn't take up a slot in the list (since we limit to 10 items). This will prevent a bunch of invalid entries in the list (which are not shown) from making valid entries dissapear off the list even when there are less than ten valid entries. See: http://code.google.com/p/msysgit/issues/detail?id=362 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-23 22:37:17 +00:00
load_config 1
git gui: de-dup selected repo from recentrepo history When the gui/user selects a repo for display, that repo is brought to the end of the recentrepo config list. The logic can fail if there are duplicate old entries for the repo (you cannot unset a single config entry when duplicates are present). Similarly, the maxrecentrepo logic could fail if older duplicate entries are present. The first commit of this series ({this}~2) fixed the config unsetting issue. Rather than manipulating a local copy of the $recent list (one cannot know how many entries were removed), simply re-read it. We must also catch the error when the attempt to remove the second copy from the re-read list is performed. Signed-off-by: Philip Oakley <philipoakley@iee.org>
2015-12-14 10:42:04 +00:00
set recent [get_config gui.recentrepo]
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
git-gui: added gui.maxrecentrepo to extend the number of remembered repos The list of recently opened repositories shown when launching git-gui from outside a repository was hard coded to only show a maximum of 10 items. This config variable allows the user to override this default. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2013-07-10 12:31:13 +00:00
if {[set maxrecent [get_config gui.maxrecentrepo]] eq {}} {
set maxrecent 10
}
while {[llength $recent] > $maxrecent} {
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
_unset_recentrepo [lindex $recent 0]
git gui: de-dup selected repo from recentrepo history When the gui/user selects a repo for display, that repo is brought to the end of the recentrepo config list. The logic can fail if there are duplicate old entries for the repo (you cannot unset a single config entry when duplicates are present). Similarly, the maxrecentrepo logic could fail if older duplicate entries are present. The first commit of this series ({this}~2) fixed the config unsetting issue. Rather than manipulating a local copy of the $recent list (one cannot know how many entries were removed), simply re-read it. We must also catch the error when the attempt to remove the second copy from the re-read list is performed. Signed-off-by: Philip Oakley <philipoakley@iee.org>
2015-12-14 10:42:04 +00:00
set recent [get_config gui.recentrepo]
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
}
}
method _open_recent {xy} {
set id [lindex [split [$w_recentlist index @$xy] .] 0]
set local_path [lindex $sorted_recent [expr {$id - 1}]]
_do_open2 $this
}
git-gui: Offer repository management features in menu bar 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-12 05:56:06 +00:00
method _open_recent_path {p} {
set local_path $p
_do_open2 $this
}
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
method _next {action} {
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
global NS
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
destroy $w_body
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
if {![winfo exists $w_next]} {
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::button $w_next -default active
git-gui: change dialog button positions for Windows to suit platform. On windows it is more common to have cancel furthest on the right. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2013-05-17 09:51:01 +00:00
set pos -before
if {[tk windowingsystem] eq "win32"} { set pos -after }
pack $w_next -side right -padx 5 $pos $w_quit
git-gui: Change repository browser radio buttons to hyperlinks 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-12 05:34:36 +00:00
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
_do_$action $this
}
method _write_local_path {args} {
if {$local_path eq {}} {
$w_next conf -state disabled
} else {
$w_next conf -state normal
}
}
method _git_init {} {
if {[catch {file mkdir $local_path} err]} {
error_popup [strcat \
[mc "Failed to create repository %s:" $local_path] \
"\n\n$err"]
return 0
}
if {[catch {cd $local_path} err]} {
error_popup [strcat \
[mc "Failed to create repository %s:" $local_path] \
"\n\n$err"]
return 0
}
if {[catch {git init} err]} {
error_popup [strcat \
[mc "Failed to create repository %s:" $local_path] \
"\n\n$err"]
return 0
}
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
_append_recentrepos [pwd]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set ::_gitdir .git
set ::_prefix {}
return 1
}
git-gui: Makes chooser set 'gitdir' to the resolved path If _is_git follows a "gitdir: ..." file link to get to the actual repository, we want _gitdir to be set to that final path. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Remi Rampin <remirampin@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2015-03-06 16:21:53 +00:00
proc _is_git {path {outdir_var ""}} {
if {$outdir_var ne ""} {
upvar 1 $outdir_var outdir
}
git-gui: allow opening work trees from the startup dialog In proc _is_git check that supplied path is a valid work tree path. This allows the choose_repository::pick dialog to accept path to a work tree directory. Signed-off-by: Mikhail Terekhov <termim@gmail.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2020-06-06 04:33:38 +00:00
if {[catch {set outdir [git rev-parse --resolve-git-dir $path]}]} {
return 0
git-gui: Support cloning Cygwin based work-dirs 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-12 20:24:20 +00:00
}
git-gui: allow opening work trees from the startup dialog In proc _is_git check that supplied path is a valid work tree path. This allows the choose_repository::pick dialog to accept path to a work tree directory. Signed-off-by: Mikhail Terekhov <termim@gmail.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2020-06-06 04:33:38 +00:00
return 1
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
git-gui: Support cloning Cygwin based work-dirs 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-12 20:24:20 +00:00
proc _objdir {path} {
set objdir [file join $path .git objects]
if {[file isdirectory $objdir]} {
return $objdir
}
set objdir [file join $path objects]
if {[file isdirectory $objdir]} {
return $objdir
}
return {}
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
######################################################################
##
## Create New Repository
method _do_new {} {
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
global use_ttk NS
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
$w_next conf \
-state disabled \
-command [cb _do_new2] \
-text [mc "Create"]
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w_body
${NS}::label $w_body.h \
-font font_uibold -anchor center \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Create New Repository"]
pack $w_body.h -side top -fill x -pady 10
pack $w_body -fill x -padx 10
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w_body.where
${NS}::label $w_body.where.l -text [mc "Directory:"]
${NS}::entry $w_body.where.t \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-textvariable @local_path \
-width 50
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::button $w_body.where.b \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Browse"] \
-command [cb _new_local_path]
git-gui: Focus insertion point at end of strings in repository chooser 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>
2008-02-11 05:53:52 +00:00
set w_localpath $w_body.where.t
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
git-gui: Vertically align textboxes with labels 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>
2008-05-19 04:01:58 +00:00
grid $w_body.where.l $w_body.where.t $w_body.where.b -sticky ew
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
pack $w_body.where -fill x
git-gui: don't hide the Browse button when resizing the repo chooser 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>
2009-03-13 23:42:37 +00:00
grid columnconfigure $w_body.where 1 -weight 1
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
trace add variable @local_path write [cb _write_local_path]
git-gui: Fix bind errors when switching repository chooser panels 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-12 15:15:02 +00:00
bind $w_body.h <Destroy> [list trace remove variable @local_path write [cb _write_local_path]]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
update
focus $w_body.where.t
}
method _new_local_path {} {
if {$local_path ne {}} {
set p [file dirname $local_path]
} else {
git-gui: instead of defaulting to home directory use working directory When starting git gui in a non-git directory it presents the user a dialog which asks to create, clone or open a repository. The filedialogs used to choose the path(s) would always default to the home directory of the user. This patch changes this behavior and uses the current working directory in which git gui was started as default. This is useful in various cases. First being that the user starts the gui in some directory and can go search to create, open or clone a repository from there. Another use case is that tools like filemanager context menues can transport a natural default when selected from a folder. Users who like to have their home folder as a default can fall back on starting git gui with its working directory set to the home folder. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2011-02-06 17:22:46 +00:00
set p [pwd]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
set p [tk_chooseDirectory \
-initialdir $p \
-parent $top \
-title [mc "Git Repository"] \
-mustexist false]
if {$p eq {}} return
set p [file normalize $p]
git-gui: Allow 'Create New Repository' on existing directories 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>
2008-01-16 06:14:42 +00:00
if {![_new_ok $p]} {
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
return
}
set local_path $p
git-gui: Focus insertion point at end of strings in repository chooser 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>
2008-02-11 05:53:52 +00:00
$w_localpath icursor end
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
method _do_new2 {} {
git-gui: Allow 'Create New Repository' on existing directories 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>
2008-01-16 06:14:42 +00:00
if {![_new_ok $local_path]} {
return
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
if {![_git_init $this]} {
return
}
set done 1
}
git-gui: Allow 'Create New Repository' on existing directories 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>
2008-01-16 06:14:42 +00:00
proc _new_ok {p} {
if {[file isdirectory $p]} {
if {[_is_git [file join $p .git]]} {
error_popup [mc "Directory %s already exists." $p]
return 0
}
} elseif {[file exists $p]} {
error_popup [mc "File %s already exists." $p]
return 0
}
return 1
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
######################################################################
##
## Clone Existing Repository
method _do_clone {} {
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
global use_ttk NS
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
$w_next conf \
-state disabled \
-command [cb _do_clone2] \
-text [mc "Clone"]
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w_body
${NS}::label $w_body.h \
-font font_uibold -anchor center \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Clone Existing Repository"]
pack $w_body.h -side top -fill x -pady 10
pack $w_body -fill x -padx 10
set args $w_body.args
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w_body.args
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
pack $args -fill both
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::label $args.origin_l -text [mc "Source Location:"]
${NS}::entry $args.origin_t \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-textvariable @origin_url \
-width 50
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::button $args.origin_b \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Browse"] \
-command [cb _open_origin]
grid $args.origin_l $args.origin_t $args.origin_b -sticky ew
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::label $args.where_l -text [mc "Target Directory:"]
${NS}::entry $args.where_t \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-textvariable @local_path \
-width 50
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::button $args.where_b \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Browse"] \
-command [cb _new_local_path]
grid $args.where_l $args.where_t $args.where_b -sticky ew
git-gui: Focus insertion point at end of strings in repository chooser 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>
2008-02-11 05:53:52 +00:00
set w_localpath $args.where_t
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::label $args.type_l -text [mc "Clone Type:"]
${NS}::frame $args.type_f
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set w_types [list]
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
lappend w_types [${NS}::radiobutton $args.type_f.hardlink \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-state disabled \
-text [mc "Standard (Fast, Semi-Redundant, Hardlinks)"] \
-variable @clone_type \
-value hardlink]
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
lappend w_types [${NS}::radiobutton $args.type_f.full \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-state disabled \
-text [mc "Full Copy (Slower, Redundant Backup)"] \
-variable @clone_type \
-value full]
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
lappend w_types [${NS}::radiobutton $args.type_f.shared \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-state disabled \
-text [mc "Shared (Fastest, Not Recommended, No Backup)"] \
-variable @clone_type \
-value shared]
foreach r $w_types {
pack $r -anchor w
}
git-gui: Add a 'recursive' checkbox in the clone menu. Permit to do a 'git clone --recursive' through git-gui. Add a 'recursive' checkbox in the clone menu which allows users to clone a repository and all its submodules in one go (unless the 'update' flag is set to "none" in the .gitmodules file for a submodule, in that case that specific submodule is not cloned automatically). Enable this new option per default, as most users want to clone all submodules too when cloning the superproject (This is currently not possible without leaving git gui or adding a custom tool entry for that). Signed-off-by: Henri GEIST <geist.henri@laposte.net> Thanks-to: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-03-11 18:21:01 +00:00
${NS}::checkbutton $args.type_f.recursive \
-text [mc "Recursively clone submodules too"] \
-variable @recursive \
-onvalue true -offvalue false
git-gui: align the new recursive checkbox with the radiobuttons. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-06-13 18:38:28 +00:00
pack $args.type_f.recursive -anchor w
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
grid $args.type_l $args.type_f -sticky new
grid columnconfigure $args 1 -weight 1
trace add variable @local_path write [cb _update_clone]
trace add variable @origin_url write [cb _update_clone]
git-gui: Fix bind errors when switching repository chooser panels 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-12 15:15:02 +00:00
bind $w_body.h <Destroy> "
[list trace remove variable @local_path write [cb _update_clone]]
[list trace remove variable @origin_url write [cb _update_clone]]
"
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
update
focus $args.origin_t
}
method _open_origin {} {
if {$origin_url ne {} && [file isdirectory $origin_url]} {
set p $origin_url
} else {
git-gui: instead of defaulting to home directory use working directory When starting git gui in a non-git directory it presents the user a dialog which asks to create, clone or open a repository. The filedialogs used to choose the path(s) would always default to the home directory of the user. This patch changes this behavior and uses the current working directory in which git gui was started as default. This is useful in various cases. First being that the user starts the gui in some directory and can go search to create, open or clone a repository from there. Another use case is that tools like filemanager context menues can transport a natural default when selected from a folder. Users who like to have their home folder as a default can fall back on starting git gui with its working directory set to the home folder. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2011-02-06 17:22:46 +00:00
set p [pwd]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
set p [tk_chooseDirectory \
-initialdir $p \
-parent $top \
-title [mc "Git Repository"] \
-mustexist true]
if {$p eq {}} return
set p [file normalize $p]
if {![_is_git [file join $p .git]] && ![_is_git $p]} {
error_popup [mc "Not a Git repository: %s" [file tail $p]]
return
}
set origin_url $p
}
method _update_clone {args} {
if {$local_path ne {} && $origin_url ne {}} {
$w_next conf -state normal
} else {
$w_next conf -state disabled
}
if {$origin_url ne {} &&
( [_is_git [file join $origin_url .git]]
|| [_is_git $origin_url])} {
set e normal
if {[[lindex $w_types 0] cget -state] eq {disabled}} {
set clone_type hardlink
}
} else {
set e disabled
set clone_type full
}
foreach r $w_types {
$r conf -state $e
}
}
method _do_clone2 {} {
if {[file isdirectory $origin_url]} {
set origin_url [file normalize $origin_url]
}
if {$clone_type eq {hardlink} && ![file isdirectory $origin_url]} {
error_popup [mc "Standard only available for local repository."]
return
}
if {$clone_type eq {shared} && ![file isdirectory $origin_url]} {
error_popup [mc "Shared only available for local repository."]
return
}
if {$clone_type eq {hardlink} || $clone_type eq {shared}} {
git-gui: Support cloning Cygwin based work-dirs 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-12 20:24:20 +00:00
set objdir [_objdir $origin_url]
if {$objdir eq {}} {
error_popup [mc "Not a Git repository: %s" [file tail $origin_url]]
return
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
}
set giturl $origin_url
git-gui: Allow 'Create New Repository' on existing directories 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>
2008-01-16 06:14:42 +00:00
if {[file exists $local_path]} {
error_popup [mc "Location %s already exists." $local_path]
return
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
if {![_git_init $this]} return
set local_path [pwd]
if {[catch {
git config remote.$origin_name.url $giturl
git config remote.$origin_name.fetch +refs/heads/*:refs/remotes/$origin_name/*
} err]} {
error_popup [strcat [mc "Failed to configure origin"] "\n\n$err"]
return
}
destroy $w_body $w_next
switch -exact -- $clone_type {
hardlink {
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
set o_status [status_bar::two_line $w_body]
git-gui: Switch the git-gui logo to Henrik Nyh's logo 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-26 18:59:09 +00:00
pack $w_body -fill x -padx 10 -pady 10
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
set status_op [$o_status start \
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
[mc "Counting objects"] \
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
[mc "buckets"]]
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
update
git-gui: Copy objects/info/alternates during standard clone 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-24 12:50:58 +00:00
if {[file exists [file join $objdir info alternates]]} {
set pwd [pwd]
if {[catch {
file mkdir [gitdir objects info]
set f_in [open [file join $objdir info alternates] r]
set f_cp [open [gitdir objects info alternates] w]
fconfigure $f_in -translation binary -encoding binary
fconfigure $f_cp -translation binary -encoding binary
cd $objdir
while {[gets $f_in line] >= 0} {
git-gui - remove obsolete Cygwin specific code In the current git release, git-gui runs on Cygwin without enabling any of git-gui's Cygwin specific code. This happens as the Cygwin specific code in git-gui was (mostly) written in 2007-2008 to work with Cygwin's then supplied Tcl/Tk which was an incompletely ported variant of the 8.4.1 Windows Tcl/Tk code. In March, 2012, that 8.4.1 package was replaced with a full port based upon the upstream unix/X11 code, since maintained up to date. The two Tcl/Tk packages are completely incompatible, and have different signatures. When Cygwin's Tcl/Tk signature changed in 2012, git-gui no longer detected Cygwin, so did not enable Cygwin specific code, and the POSIX environment provided by Cygwin since 2012 supported git-gui as a generic unix. Thus, no-one apparently noticed the existence of incompatible Cygwin specific code. However, since commit c5766eae6f in the git-gui source tree (https://github.com/prati0100/git-gui, master at a5005ded), and not yet pulled into the git repository, the is_Cygwin function does detect Cygwin using the unix/X11 Tcl/Tk. The Cygwin specific code is enabled, causing use of Windows rather than unix pathnames, and enabling incorrect warnings about environment variables that were relevant only to the old Tcl/Tk. The end result is that (upstream) git-gui is now incompatible with Cygwin. So, delete Cygwin specific code (code protected by "if is_Cygwin") that is not needed in any form to work with the unix/X11 Tcl/Tk. Cygwin specific code required to enable file browsing and shortcut creation is not addressed in this patch, does not currently work, and invocation of those items may leave git-gui in a confused state. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2023-06-26 16:53:03 +00:00
puts $f_cp [file normalize $line]
git-gui: Copy objects/info/alternates during standard clone 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-24 12:50:58 +00:00
}
close $f_in
close $f_cp
cd $pwd
} err]} {
catch {cd $pwd}
_clone_failed $this [mc "Unable to copy objects/info/alternates: %s" $err]
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op stop
git-gui: Copy objects/info/alternates during standard clone 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-24 12:50:58 +00:00
return
}
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set tolink [list]
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
set buckets [glob \
-tails \
-nocomplain \
-directory [file join $objdir] ??]
set bcnt [expr {[llength $buckets] + 2}]
set bcur 1
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op update $bcur $bcnt
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
update
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
file mkdir [file join .git objects pack]
foreach i [glob -tails -nocomplain \
-directory [file join $objdir pack] *] {
lappend tolink [file join pack $i]
}
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op update [incr bcur] $bcnt
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
update
foreach i $buckets {
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
file mkdir [file join .git objects $i]
foreach j [glob -tails -nocomplain \
-directory [file join $objdir $i] *] {
lappend tolink [file join $i $j]
}
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op update [incr bcur] $bcnt
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
update
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op stop
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
if {$tolink eq {}} {
info_popup [strcat \
[mc "Nothing to clone from %s." $origin_url] \
"\n" \
[mc "The 'master' branch has not been initialized."] \
]
git-gui: Keep the UI responsive while counting objects in clone 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-24 12:40:44 +00:00
destroy $w_body
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set done 1
return
}
set i [lindex $tolink 0]
if {[catch {
file link -hard \
[file join .git objects $i] \
[file join $objdir $i]
} err]} {
git-gui: Don't bother showing OS error message about hardlinks 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-24 12:26:07 +00:00
info_popup [mc "Hardlinks are unavailable. Falling back to copying."]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set i [_copy_files $this $objdir $tolink]
} else {
set i [_link_files $this $objdir [lrange $tolink 1 end]]
}
if {!$i} return
destroy $w_body
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
set o_status {}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
full {
set o_cons [console::embed \
$w_body \
[mc "Cloning from %s" $origin_url]]
pack $w_body -fill both -expand 1 -padx 10
$o_cons exec \
[list git fetch --no-tags -k $origin_name] \
[cb _do_clone_tags]
}
shared {
set fd [open [gitdir objects info alternates] w]
fconfigure $fd -translation binary
puts $fd $objdir
close $fd
}
}
if {$clone_type eq {hardlink} || $clone_type eq {shared}} {
if {![_clone_refs $this]} return
set pwd [pwd]
if {[catch {
cd $origin_url
set HEAD [git rev-parse --verify HEAD^0]
} err]} {
_clone_failed $this [mc "Not a Git repository: %s" [file tail $origin_url]]
return 0
}
cd $pwd
_do_clone_checkout $this $HEAD
}
}
method _copy_files {objdir tocopy} {
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
set status_op [$o_status start \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
[mc "Copying objects"] \
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
[mc "KiB"]]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set tot 0
set cmp 0
foreach p $tocopy {
incr tot [file size [file join $objdir $p]]
}
foreach p $tocopy {
if {[catch {
set f_in [open [file join $objdir $p] r]
set f_cp [open [file join .git objects $p] w]
fconfigure $f_in -translation binary -encoding binary
fconfigure $f_cp -translation binary -encoding binary
while {![eof $f_in]} {
incr cmp [fcopy $f_in $f_cp -size 16384]
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op update \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
[expr {$cmp / 1024}] \
[expr {$tot / 1024}]
update
}
close $f_in
close $f_cp
} err]} {
_clone_failed $this [mc "Unable to copy object: %s" $err]
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op stop
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
return 0
}
}
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op stop
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
return 1
}
method _link_files {objdir tolink} {
set total [llength $tolink]
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
set status_op [$o_status start \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
[mc "Linking objects"] \
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
[mc "objects"]]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
for {set i 0} {$i < $total} {} {
set p [lindex $tolink $i]
if {[catch {
file link -hard \
[file join .git objects $p] \
[file join $objdir $p]
} err]} {
_clone_failed $this [mc "Unable to hardlink object: %s" $err]
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op stop
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
return 0
}
incr i
if {$i % 5 == 0} {
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op update $i $total
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
update
}
}
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$status_op stop
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
return 1
}
method _clone_refs {} {
set pwd [pwd]
if {[catch {cd $origin_url} err]} {
error_popup [mc "Not a Git repository: %s" [file tail $origin_url]]
return 0
}
set fd_in [git_read for-each-ref \
--tcl \
{--format=list %(refname) %(objectname) %(*objectname)}]
cd $pwd
set fd [open [gitdir packed-refs] w]
fconfigure $fd -translation binary
puts $fd "# pack-refs with: peeled"
while {[gets $fd_in line] >= 0} {
set line [eval $line]
set refn [lindex $line 0]
set robj [lindex $line 1]
set tobj [lindex $line 2]
if {[regsub ^refs/heads/ $refn \
"refs/remotes/$origin_name/" refn]} {
puts $fd "$robj $refn"
} elseif {[string match refs/tags/* $refn]} {
puts $fd "$robj $refn"
if {$tobj ne {}} {
puts $fd "^$tobj"
}
}
}
close $fd_in
close $fd
return 1
}
method _do_clone_tags {ok} {
if {$ok} {
$o_cons exec \
[list git fetch --tags -k $origin_name] \
[cb _do_clone_HEAD]
} else {
$o_cons done $ok
_clone_failed $this [mc "Cannot fetch branches and objects. See console output for details."]
}
}
method _do_clone_HEAD {ok} {
if {$ok} {
$o_cons exec \
[list git fetch $origin_name HEAD] \
[cb _do_clone_full_end]
} else {
$o_cons done $ok
_clone_failed $this [mc "Cannot fetch tags. See console output for details."]
}
}
method _do_clone_full_end {ok} {
$o_cons done $ok
if {$ok} {
destroy $w_body
set HEAD {}
if {[file exists [gitdir FETCH_HEAD]]} {
set fd [open [gitdir FETCH_HEAD] r]
while {[gets $fd line] >= 0} {
if {[regexp "^(.{40})\t\t" $line line HEAD]} {
break
}
}
close $fd
}
catch {git pack-refs}
_do_clone_checkout $this $HEAD
} else {
_clone_failed $this [mc "Cannot determine HEAD. See console output for details."]
}
}
method _clone_failed {{why {}}} {
if {[catch {file delete -force $local_path} err]} {
set why [strcat \
$why \
"\n\n" \
[mc "Unable to cleanup %s" $local_path] \
"\n\n" \
$err]
}
if {$why ne {}} {
update
error_popup [strcat [mc "Clone failed."] "\n" $why]
}
}
method _do_clone_checkout {HEAD} {
if {$HEAD eq {}} {
info_popup [strcat \
[mc "No default branch obtained."] \
"\n" \
[mc "The 'master' branch has not been initialized."] \
]
set done 1
return
}
if {[catch {
git update-ref HEAD $HEAD^0
} err]} {
info_popup [strcat \
[mc "Cannot resolve %s as a commit." $HEAD^0] \
"\n $err" \
"\n" \
[mc "The 'master' branch has not been initialized."] \
]
set done 1
return
}
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
set status [status_bar::two_line $w_body]
git-gui: Switch the git-gui logo to Henrik Nyh's logo 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-26 18:59:09 +00:00
pack $w_body -fill x -padx 10 -pady 10
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
# We start the status operation here.
#
# This function calls _readtree_wait as a callback.
#
# _readtree_wait in turn either calls _do_clone_submodules directly,
# or calls _postcheckout_wait as a callback which then calls
# _do_clone_submodules.
#
# _do_clone_submodules calls _do_validate_submodule_cloning.
#
# _do_validate_submodule_cloning stops the status operation.
#
# There are no other calls into this chain from other code.
set o_status_op [$status start \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
[mc "Creating working directory"] \
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
[mc "files"]]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set readtree_err {}
set fd [git_read --stderr read-tree \
-m \
-u \
-v \
HEAD \
HEAD \
]
fconfigure $fd -blocking 0 -translation binary
fileevent $fd readable [cb _readtree_wait $fd]
}
method _readtree_wait {fd} {
set buf [read $fd]
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
$o_status_op update_meter $buf
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
append readtree_err $buf
fconfigure $fd -blocking 1
if {![eof $fd]} {
fconfigure $fd -blocking 0
return
}
if {[catch {close $fd}]} {
set err $readtree_err
regsub {^fatal: } $err {} err
error_popup [strcat \
[mc "Initial file checkout failed."] \
"\n\n$err"]
return
}
git-gui: run post-checkout hook after clone git-gui is using "git-read-tree -u" when cloning which doesn't invoke the post-checkout hook as a plain git-clone would. So git-gui must call the hook itself. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-04-06 19:05:55 +00:00
# -- Run the post-checkout hook.
#
set fd_ph [githook_read post-checkout [string repeat 0 40] \
[git rev-parse HEAD] 1]
if {$fd_ph ne {}} {
global pch_error
set pch_error {}
fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
fileevent $fd_ph readable [cb _postcheckout_wait $fd_ph]
} else {
git-gui: Add a 'recursive' checkbox in the clone menu. Permit to do a 'git clone --recursive' through git-gui. Add a 'recursive' checkbox in the clone menu which allows users to clone a repository and all its submodules in one go (unless the 'update' flag is set to "none" in the .gitmodules file for a submodule, in that case that specific submodule is not cloned automatically). Enable this new option per default, as most users want to clone all submodules too when cloning the superproject (This is currently not possible without leaving git gui or adding a custom tool entry for that). Signed-off-by: Henri GEIST <geist.henri@laposte.net> Thanks-to: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-03-11 18:21:01 +00:00
_do_clone_submodules $this
git-gui: run post-checkout hook after clone git-gui is using "git-read-tree -u" when cloning which doesn't invoke the post-checkout hook as a plain git-clone would. So git-gui must call the hook itself. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-04-06 19:05:55 +00:00
}
}
method _postcheckout_wait {fd_ph} {
global pch_error
append pch_error [read $fd_ph]
fconfigure $fd_ph -blocking 1
if {[eof $fd_ph]} {
if {[catch {close $fd_ph}]} {
hook_failed_popup post-checkout $pch_error 0
}
unset pch_error
git-gui: Add a 'recursive' checkbox in the clone menu. Permit to do a 'git clone --recursive' through git-gui. Add a 'recursive' checkbox in the clone menu which allows users to clone a repository and all its submodules in one go (unless the 'update' flag is set to "none" in the .gitmodules file for a submodule, in that case that specific submodule is not cloned automatically). Enable this new option per default, as most users want to clone all submodules too when cloning the superproject (This is currently not possible without leaving git gui or adding a custom tool entry for that). Signed-off-by: Henri GEIST <geist.henri@laposte.net> Thanks-to: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-03-11 18:21:01 +00:00
_do_clone_submodules $this
git-gui: run post-checkout hook after clone git-gui is using "git-read-tree -u" when cloning which doesn't invoke the post-checkout hook as a plain git-clone would. So git-gui must call the hook itself. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-04-06 19:05:55 +00:00
return
}
fconfigure $fd_ph -blocking 0
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
git-gui: update status bar to track operations Update the status bar to track updates as individual "operations" that can overlap. Update all call sites to interact with the new status bar mechanism. Update initialization to explicitly clear status text, since otherwise it may persist across future operations. Signed-off-by: Jonathan Gilbert <JonathanG@iQmetrix.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2019-12-01 02:28:32 +00:00
method _do_clone_submodules {} {
if {$recursive eq {true}} {
$o_status_op stop
set o_status_op {}
destroy $w_body
set o_cons [console::embed \
$w_body \
[mc "Cloning submodules"]]
pack $w_body -fill both -expand 1 -padx 10
$o_cons exec \
[list git submodule update --init --recursive] \
[cb _do_validate_submodule_cloning]
} else {
set done 1
}
}
method _do_validate_submodule_cloning {ok} {
if {$ok} {
$o_cons done $ok
set done 1
} else {
_clone_failed $this [mc "Cannot clone submodules."]
}
}
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
######################################################################
##
## Open Existing Repository
method _do_open {} {
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
global NS
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
$w_next conf \
-state disabled \
-command [cb _do_open2] \
-text [mc "Open"]
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w_body
${NS}::label $w_body.h \
-font font_uibold -anchor center \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Open Existing Repository"]
pack $w_body.h -side top -fill x -pady 10
pack $w_body -fill x -padx 10
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::frame $w_body.where
${NS}::label $w_body.where.l -text [mc "Repository:"]
${NS}::entry $w_body.where.t \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-textvariable @local_path \
-width 50
git-gui: use themed tk widgets with Tk 8.5 This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-26 00:05:31 +00:00
${NS}::button $w_body.where.b \
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
-text [mc "Browse"] \
-command [cb _open_local_path]
git-gui: Vertically align textboxes with labels 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>
2008-05-19 04:01:58 +00:00
grid $w_body.where.l $w_body.where.t $w_body.where.b -sticky ew
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
pack $w_body.where -fill x
git-gui: don't hide the Browse button when resizing the repo chooser 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>
2009-03-13 23:42:37 +00:00
grid columnconfigure $w_body.where 1 -weight 1
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
trace add variable @local_path write [cb _write_local_path]
git-gui: Fix bind errors when switching repository chooser panels 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-12 15:15:02 +00:00
bind $w_body.h <Destroy> [list trace remove variable @local_path write [cb _write_local_path]]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
update
focus $w_body.where.t
}
method _open_local_path {} {
if {$local_path ne {}} {
set p $local_path
} else {
git-gui: instead of defaulting to home directory use working directory When starting git gui in a non-git directory it presents the user a dialog which asks to create, clone or open a repository. The filedialogs used to choose the path(s) would always default to the home directory of the user. This patch changes this behavior and uses the current working directory in which git gui was started as default. This is useful in various cases. First being that the user starts the gui in some directory and can go search to create, open or clone a repository from there. Another use case is that tools like filemanager context menues can transport a natural default when selected from a folder. Users who like to have their home folder as a default can fall back on starting git gui with its working directory set to the home folder. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2011-02-06 17:22:46 +00:00
set p [pwd]
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
}
set p [tk_chooseDirectory \
-initialdir $p \
-parent $top \
-title [mc "Git Repository"] \
-mustexist true]
if {$p eq {}} return
set p [file normalize $p]
if {![_is_git [file join $p .git]]} {
error_popup [mc "Not a Git repository: %s" [file tail $p]]
return
}
set local_path $p
}
method _do_open2 {} {
git-gui: Makes chooser set 'gitdir' to the resolved path If _is_git follows a "gitdir: ..." file link to get to the actual repository, we want _gitdir to be set to that final path. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Remi Rampin <remirampin@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2015-03-06 16:21:53 +00:00
if {![_is_git [file join $local_path .git] actualgit]} {
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
error_popup [mc "Not a Git repository: %s" [file tail $local_path]]
return
}
if {[catch {cd $local_path} err]} {
error_popup [strcat \
[mc "Failed to open repository %s:" $local_path] \
"\n\n$err"]
return
}
git-gui: offer a list of recent repositories on startup 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-08 06:25:47 +00:00
_append_recentrepos [pwd]
git-gui: Makes chooser set 'gitdir' to the resolved path If _is_git follows a "gitdir: ..." file link to get to the actual repository, we want _gitdir to be set to that final path. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Remi Rampin <remirampin@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2015-03-06 16:21:53 +00:00
set ::_gitdir $actualgit
git-gui: Allow users to choose/create/clone a repository 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>
2007-09-22 07:47:43 +00:00
set ::_prefix {}
set done 1
}
}
Reference in a new issue Copy permalink