- 12 10月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
The parsing for the output of `git config --list` is the same for both the global options and the current repository's options so we can really just use the same parser between them. I'm currently just refactoring the parser so we can use a different one depending on the version of git available to us at runtime. My next change will add support for 1.5.3's --null option. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
To better handle configuration options that contain LFs in their values we want to use the new -z option available in git-config version 1.5.3 and later. To configure load_config based upon the git version we need to move thos below the git-version computation. No logic changes yet, just a minor reordering of the code. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Johannes Sixt 提交于
The layout is changed to have the file lists at the left (Unstaged Changes at the top, Staged Changes below it) and the diff window at the right (with the commit area below it). +----------+---------------------+ | Unstaged | Diff area | | | | | | | | | | +----------+ | | Staged | | | +---------------------+ | | Commit area | | | | +----------+---------------------+ The advantages are: - The height of the file lists can be adjusted independently to fit the files that they contain. - The diff viewer is higher. On wide screens it is ok that the main window is now generally wider, too. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 10 10月, 2007 4 次提交
-
-
由 Steffen Prohaska 提交于
This commit modifies PATH to include a good guess where git could be found. The first location to search for executable is the directory git-gui is installed in. This is a good guess for a sane installation. Even if git is not available in PATH, git-gui is now able to find it. Hence git-gui can be passed to wish as an absolute path without caring about the environment. We must modify PATH to be able to spawn shell based git commands. For builtins it would be sufficient to located them and execute them with their absolute path. But for shell based git commmands PATH needs to be modified. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The titles for the staged and unstaged areas were usually opening up too narrow by default, causing the text to be clipped by Tcl as it tried to center the text in the middle of the available area. This meant that users who were new to git-gui did not get to see the entire header and may be unclear about what the different lists are. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
A Mac OS X UI convention is to have Cmd-, be the accelerator key for the preferences window, which by convention is located in the apple menu under a separator below the about command. We also now call this "Preferences..." as that is the conventional term used in English. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Sometimes the Fetch menu looks really odd, such as if you are in a repository that has no remotes configured when you start git-gui. Here we didn't have any items to add to the Fetch menu so it was a tad confusing for the end-user to see an empty menu on the menu bar. We now place all of the commands related to fetching and pushing of changes into a single "Remote" menu. This way we have a better class of bucket that we can drop additional remote related items into such as doing a remote merge or editing the remote configuration specs. The shortcuts to execute fetch/remote prune/push on existing remote specifications are now actually submenus listing the remotes by name. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 08 10月, 2007 1 次提交
-
-
由 Steffen Prohaska 提交于
This commit teaches git-gui to accept versions with annotations that start with text and optionally end with a dot followed by a number. This is needed by the current versioning scheme of msysgit, which uses versions like 1.5.3.mingw.1. However, the changes is not limited to this use case. Any version of the form <numeric version>.<anytext>.<number> would be parsed and only the starting <numeric version> used for validation. [sp: Minor edit to remove unnecessary group matching] Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 03 10月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
If the user has started git-gui from the command line as a browser we offer the gitk menu options but we didn't create the main status bar widget in the "." toplevel. Trying to access it while starting gitk just results in Tcl errors. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
gitk expects $env(GIT_DIR) to be valid as both a path that core Git and Tcl/Tk can resolve to a valid directory, but it has no special handling for Cygwin style UNIX paths and Windows style paths. So we need to do that for gitk and ensure that only relative paths are fed to it, thus allowing both Cygwin style and UNIX style paths to be resolved. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 28 9月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
When displaying the name of the application in window titles and menu options (e.g. "About [appname]") we would prefer to call ourselves "Git Gui" over "git-gui" as the former name is now being actively used in the Mac OS X UI strings and just plain looks better to the reader. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than displaying the stock red "Tk" icon in our window title bars and on the task bar we now show a Git specific logo. This is Henrik Nyh's logo that we also use in the startup wizard, scaled to a 16x16 image for Windows task bar usage with a proper transparent background. Signed-off-by: NShawn O. Pearce <shawn.o.pearce@bankofamerica.com>
-
- 23 9月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org>
-
- 22 9月, 2007 4 次提交
-
-
由 Shawn O. Pearce 提交于
I'm starting to setup a main window that the user can use to locate an existing repository, clone an existing repository, or create a new repository from scratch. To help do that I want most of our common UI support already defined before we start to look for the Git repository, this way if it was not found we can open a window to help the user locate it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we are using Cygwin and the git repository is actually a workdir (by way of git-new-workdir) but this Tcl process is a native Tcl/Tk and not the Cygwin Tcl/Tk then we are unable to traverse the .git/info path as it is a Cygwin symlink and not a standard Windows directory. So we actually need to start a Cygwin process that can do the path translation for us and let it test for .git/info/exclude so we know if we can include that file in our git-ls-files or not. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I really cannot explain Cygwin's behavior here but if we start git-gui through Cygwin on a local drive it appears that Cygwin is leaving $env(PATH) in Unix style, even if it started a native (non-Cygwin) Tcl/Tk process to run git-gui. Yet starting that same git-gui and Tcl/Tk combination through Cygwin on a network share causes it to automatically convert $env(PATH) into Windows style, which broke our internal "which" implementation. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we cannot find the git executable in the user's $PATH then we cannot function correctly. Because we need that to get the version so we can load our library correctly we cannot rely on the library function "error_popup" here, as this is all running before the library path has been configured, so error_popup is not available to us. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 21 9月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
Cygwin has been stuck on the 8.4.1 version of Tcl/Tk for quite some time, even though the main Tcl/Tk distribution is already shipping an 8.4.15. The problem is Tcl/Tk no longer supports Cygwin so apparently building the package for Cygwin is now a non-trivial task. Its actually quite easy to build the native Win32 version of Tcl/Tk by compiling with the -mno-cygwin flag passed to GCC but this means we lose all of the "fancy" Cygwin path translations that the Tcl library was doing for us. This is particularly an issue when we are trying to start git-gui through the git wrapper as the git wrapper is passing off a Cygwin path for $0 and Tcl cannot find the startup script or the library directory. We now use `cygpath -m -a` to convert the UNIX style paths to Windows style paths in our startup script if we are building on Cygwin. Doing so allows either the Cygwin-ized Tcl/Tk 8.4.1 that comes with Cygwin or a manually built 8.4.15 that is running the pure Win32 implementation to read our script. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Simon Sasburg 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 17 9月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Sometimes we use a Tk text widget as though it were a listbox. This happens typically when we want to show an icon to the left of the text label or just when a text widget is generally a better choice then the native listbox widget. In these cases if we want the user to have control over the selection we implement our own "in_sel" tag that shows the selected region and we perform our own selection management in the background via keybindings and mouse bindings. In such uses we don't want the user to be able to activate the native platform selection by dragging their mouse through the text widget. Doing so creates a very confusing display and the user is left wondering what it may mean to have two different types of selection in the same widget. Tk doesn't allow us to delete the "sel" tag that it uses internally to manage the native selection but it will allow us to make it invisible by setting the tag to have the same display properties as unselected text. So long as we don't actually use the "sel" tag for anything in code its effectively invisible. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 14 9月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
The Tcl expression "[append [mc Foo] Bar]" does not return the string "FooBar" after translation; instead it is setting the variable Foo to the value Bar, or if Foo is already defined it is appending Bar onto the end of it. This is *not* what we wanted to have happen here. Tcl's join function is actually the correct function but its default joinStr argument is a single space. Unfortunately all of our call sites do not want an extra space added to their string. So we need a small wrapper function to make the call to join with an empty join string. In C this is (roughly) the job of the strcat function. Since strcat is not yet used at the global level it is a reasonable name to use here. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Michele Ballabio 提交于
Most of these changes were suggested by Shawn Pearce in an answer to Johannes Schindelin. Some strings for the blame module were added too. [sp: Minor edits in blame module formatting] Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This is a very trivial hack to define a global mc procedure that does not actually perform i18n translations on its input strings. By declaring an mc procedure here in our maint version of git-gui we can take patches that are intended for the latest development version of git-gui and easily backport them without needing to tweak the mc calls first. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 13 9月, 2007 2 次提交
-
-
Commit is used as both verb and noun. While these happen to be the same in some languages, they are not the same in all languages, so disambiguate them using context-sensitive i18n. Signed-off-by: NHarri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Ocassionally, one would want to translate the same string used in different contexts in diffrent ways. This patch provides a wrapper for msgcat::mc that trims "@@" and anything coming after it, whether or not the string actually got translated. Proposed-by: NHarri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 12 9月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
The Windows port of Tk does not have the send command so we cannot delete it from our global namespace, but the Mac OS X and X11 ports do have it. Switching this delete attempt into a catch makes send go away, or stay away. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 10 9月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Oddly enough `git ls-files --others` supplies us the name of an untracked submodule by including the trailing slash but that same git version will not accept the name with a trailing slash through `git update-index --stdin`. Stripping off that final slash character before loading it into our file lists allows git-gui to stage changes to submodules just like any other file. This change should give git-gui users some basic submodule support, but it is strictly at the plumbing level as we do not actually know about calling the git-submodule porcelain that is a recent addition to git 1.5.3. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 09 9月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
The Tk designers blessed us with the "send" command, which on X11 will allow anyone who can connect to your X server to evaluate any Tcl code they desire within any running Tk process. This is just plain nuts. If git-gui wants someone running Tcl code within it then would ask someone to supply that Tcl code to it; waiting for someone to drop any random Tcl code into us is not fantastic idea. By renaming send to the empty name the procedure will be removed from the global namespace and Tk will stop responding to random Tcl evaluation requests sent through the X server. Since there is no facility to filter these requests it is unlikely that we will ever consider enabling this command. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 04 9月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
Today I found yet another way for the "Stage Hunk" and "Unstage Hunk" context menu actions to leave the wrong state enabled in the UI. The problem this time was that I connected the state determination to the value of $::current_diff_side (the side the diff is from). When the user was last looking at a diff from the index side and unstages everything the diff panel goes empty, but the action stayed enabled as we always assumed unstaging was a valid action. This change moves the logic for determining when the action is enabled away from the individual side selection, as they really are two unrelated concepts. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Current versions of git-remote apparently are passing the -w option to Perl as part of the shbang line: #!/usr/bin/perl -w this caused a problem in git-gui and gave the user a Tcl error with the message: "git-remote not supported: #!/usr/bin/perl -w". The fix for this is to treat the shbang line as a Tcl list and look at the first element only for guessing the executable name. Once we know the executable name we use the remaining elements (if any exist) as arguments to the executable, before the script filename. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 03 9月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
This particular message is talking about a specific option in the configuration file named "gui.$name". This option is not localized so we cannot localize the "gui." that denotes the section the option $name is found within. Currently there are no plans to localize the configuration options for git-gui, but if that were to change in the future then it would be necessary to localize not only the "gui." section prefix but also the $name (fontui and fontdiff). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 02 9月, 2007 3 次提交
-
-
由 Christian Stimming 提交于
The procedure [mc ...] will translate the strings through msgcat. Strings must be enclosed in quotes, not in braces, because otherwise xgettext cannot extract them properly, although on the Tcl side both delimiters would work fine. [jes: I merged the later patches to that end.] Signed-off-by: NChristian Stimming <stimming@tuhh.de> Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
-
由 Shawn O. Pearce 提交于
Tcl's msgcat library and corresponding mc procedure can locate a translated string for any user message, provided that it is first given a directory where the *.msg files are located containing the translations. During installation we will place the translations in lib/msgs/, so we need to inform msgcat of this location once we determine it during startup. Our source code tree however will store all of the translations within the po/ directory, so we need to special case this variant. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
To support a localized version of git-gui we need to locate the library directory early so we can initialize Tcl's msgcat package to load translated messages from. This needs to occur before we declare our git-version proc so that errors related to locating git or assessing its version can be reported to the end-user in their preferred language. However we have to keep the library loading until after git-version has been declared, otherwise we will fail to start git-gui if we are using a fake tclIndex that was generated by our Makefile. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 25 8月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
David Kastrup pointed out that the following sequence was not working as we had intended: $ cd lib $ git gui blame console.tcl fatal: cannot stat path lib/console.tcl: No such file or directory The problem here was we disabled the chdir to the root of the working tree when we are running with a "bare allowed" feature such as blame or browser, but we still kept the prefix we found via `git rev-parse --show-prefix`. This caused us to try and look for the file "console.tcl" within the subdirectory but also include the subdirectory's own path from the root of the working tree. This is unlikely to succeed, unless the user just happened to have a "lib/lib/console.tcl" file in the repository, in which case we would produce the wrong result. In the case of a bare repository we shouldn't get back a value from `rev-parse --show-prefix`, so really $_prefix should only be set to the non-empty string if we are in a working tree and we are in a subdirectory of that working tree. If this is true we really want to always be at the top level of the working tree, as all paths are accessed as though they were relative to the top of the working tree. Converting $_prefix to a ../ sequence is a fairly simple approach to moving up the requisite levels. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 23 8月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
git-apply does not accept a patch that was generated as a three-way combined diff format such as we see during merge conflicts. If we get such a diff in our diff viewer and try to send it to git-apply it just errors out and the user is left confused wondering why they cannot stage that hunk. Instead of feeding a known to be unacceptable hunk to git-apply we now just disable the stage/unstage context menu option if the hunk came from a three way diff. The user may still be confused about why they cannot work with a combined diff, but at least they are only confused as to why git-gui is not offering them the action. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The current popup_diff_menu procedure is somewhat messy as it has a few duplications of the same logic in each of the different legs of the routine. We can simplify these by setting a few state variables in the different legs. No functional change, just a cleanup to make it easier to implement future functional changes within this block. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 22 8月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
If the tclsh command was not available to us at the time we were "built" our lib/tclIndex just lists all of our library files and we source all of them at once during startup, rather than trying to lazily load only the procedures we need. This is a problem as some of our library code now depends upon the git-version proc, and that proc is not defined until after the library was fully loaded. I'm moving the library loading until after we have determined the version of git we are talking to, as this ensures that the required git-reversion procedure is defined before any library code can be loaded. Since error_popup is defined in the library we instead use tk_messageBox directly for errors found during the version detection. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 21 8月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
In a13ee29b I totally broke the "Stage Hunk For Commit" feature by making this menu item always appear in a disabled state, so it was never invokable. A "teaser feature", just sitting there taunting the poor user who has become used to having it available. The issue caused by a13ee was I added a test to look at the data in $file_states, but I didn't do that test correctly as it was always looking at a procedure local $file_states array, which is not defined, so the test was always true and we always disabled the menu entry. Instead we only want to disable the menu entry if the current file we are looking at has no file state information (git-gui is just a very confused little process) or it is an untracked file (and we cannot stage individual hunks). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 20 8月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
cehteh on #git noticed that secondary windows such as console windows from push/fetch/merge or the blame browser failed on ion when we tried to open them a second time. The issue turned out to be the fact that on ion [winfo ismapped .] returns false if . is not visible right now because it has been obscured by another window in the same panel. So we need to keep track of whether or not the root window has been displayed for this application, and once it has been we cannot ever assume that ismapped is going to return true. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-