- 25 9月, 2008 2 次提交
-
-
由 Alexander Gavrilov 提交于
To make encoding selection easier, add a menu that lists available encodings to the Options window. Menu structure is borrowed from Firefox. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Tested-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
- Make diffs and blame default to the system (locale) encoding instead of hard-coding UTF-8. - Add a gui.encoding option to allow overriding it. - gitattributes still have the final word. The rationale for this is Windows support: 1) Windows people are accustomed to using legacy encodings for text files. For many of them defaulting to utf-8 will be counter-intuitive. 2) Windows doesn't support utf-8 locales, and switching the system encoding is a real pain. Thus the option. This patch also adds proper encoding conversion to Apply Hunk/Line. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Tested-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 05 9月, 2008 1 次提交
-
-
由 Alexander Gavrilov 提交于
Adds an item to the diff context menu in conflict mode, which invokes a merge tool for the selected file. Tool command-line handling code was ported from git-mergetool. Automatic default tool selection and custom merge tools are not supported. If merge.tool is not set, git-gui defaults to meld. This implementation uses a checkout-index hack in order to retrieve all stages with autocrlf and filters properly applied. It requires temporarily moving the original conflict file out of the way. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 02 9月, 2008 1 次提交
-
-
由 Clemens Buchacher 提交于
Staging hunks without context does not work, because line number information would have to be recomputed for individual hunks. Since it is already possible to stage individual lines using 'Stage Line for Commit', zero context diffs are not really necessary for git gui. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 25 8月, 2008 1 次提交
-
-
由 Alexander Gavrilov 提交于
Add a context menu command to load commits that are within a certain time range from the selected commit into gitk. It can be useful for understanding of the code, especially if the repository is imported from a VCS that does not support atomic commits. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 17 7月, 2008 1 次提交
-
-
由 Alexander Gavrilov 提交于
On huge repositories, -C -C can be way too slow to be unconditionally enabled, and it can also be useful to control its precision. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 08 3月, 2008 1 次提交
-
-
由 Adam Piątyszek 提交于
The width of the commit message text area is currently hard-coded to 75 characters. This value might be not optimal for some projects. For instance users who would like to generate GNU-style ChangeLog file from git commit message might prefer commit messages of width no longer than 70 characters. This patch adds a global and per repository option "Commit Message Text Width", which could be used to change the width of the commit message text area. Signed-off-by: NAdam Piątyszek <ediap@users.sourceforge.net> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 14 2月, 2008 1 次提交
-
-
由 Shawn O. Pearce 提交于
We don't need to fill this entire horizontal cavity, it looks really bad on some platforms to stretch the widget out to fill the window. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 12 2月, 2008 1 次提交
-
-
由 Shawn O. Pearce 提交于
Many user friendly tools like word processors, email editors and web browsers allow users to spell check the message they are writing as they type it, making it easy to identify a common misspelling of a word and correct it on the fly. We now open a bi-directional pipe to Aspell and feed the message text the user is editing off to the program about once every 300 milliseconds. This is frequent enough that the user sees the results almost immediately, but is not so frequent as to cause significant additional load on the system. If the user has modified the message text during the last 300 milliseconds we delay until the next period, ensuring that we avoid flooding the Aspell process with a lot of text while the user is actively typing their message. We wait to send the current message buffer to Aspell until the user is at a word boundary, thus ensuring that we are not likely to ask for misspelled word detection on a word that the user is actively typing, as most words are misspelled when only partially typed, even if the user has thus far typed it correctly. Misspelled words are highlighted in red and are given an underline, causing the word to stand out from the others in the buffer. This is a very common user interface idiom for displaying misspelled words, but differs from one platform to the next in slight variations. For example the Mac OS X system prefers using a dashed red underline, leaving the word in the original text color. Unfortunately the control that Tk gives us over text display is not powerful enough to handle such formatting so we have to work with the least common denominator. The top suggestions for a misspelling are saved in an array and offered to the user when they right-click (or on the Mac ctrl-click) a misspelled word. Selecting an entry from this menu will replace the misspelling with the correction shown. Replacement is integrated with the undo/redo stack so undoing a replacement will restore the misspelled original text. If Aspell could not be started during git-gui launch we silently eat the error and run without spell checking support. This way users who do not have Aspell in their $PATH can continue to use git-gui, although they will not get the advanced spelling functionality. If Aspell started successfully the version line and language are shown in git-gui's about box, below the Tcl/Tk versions. This way the user can verify the Aspell function has been activated. If Aspell crashes while we are running we inform the user with an error dialog and then disable Aspell entirely for the rest of this git-gui session. This prevents us from fork-bombing the system with Aspell instances that always crash when presented with the current message text, should there be a bug in either Aspell or in git-gui's output to it. We escape all input lines with ^, as recommended by the Aspell manual page, as this allows Aspell to properly ignore any input line that is otherwise looking like a command (e.g. ! to enable terse output). By using this escape however we need to correct all word offsets by -1 as Aspell is apparently considering the ^ escape to be part of the line's character count, but our Tk text widget obviously does not. Available dictionaries are offered in the Options dialog, allowing the user to select the language they want to spellcheck commit messages with for the current repository, as well as the global user setting that all repositories inherit. Special thanks to Adam Flott for suggesting connecting git-gui to Aspell for the purpose of spell checking the commit message, and to Wincent Colaiuta for the idea to wait for a word boundary before passing the message over for checking. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 10 10月, 2007 2 次提交
-
-
由 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 提交于
The about dialog is getting somewhat long in size and will probably only get more complex as I try to improve upon its display. As the options dialog is even more complex than the about dialog we move the about dialog into its own module to reduce the complexity of the option dialog module. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 14 9月, 2007 2 次提交
-
-
由 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>
-
由 Shawn O. Pearce 提交于
Simon Sasburg noticed that on X11 if there are more fonts than can fit in the height of the screen Tk's native tk_optionMenu does not offer scroll arrows to the user and it is not possible to review all choices or to select those that are off-screen. On Mac OS X the tk_optionMenu works properly but is awkward to navigate if the list is long. This is a rewrite of our font selection by providing a new modal dialog that the user can launch from the git-gui Options panel. The dialog offers the user a scrolling list of fonts in a pane. An example text shows the user what the font looks like at the size they have selected. But I have to admit the example pane is less than ideal. For example in the case of our diff font we really should show the user an example diff complete with our native diff syntax coloring. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Acked-by: NSimon Sasburg <simon.sasburg@gmail.com>
-
- 02 9月, 2007 1 次提交
-
-
由 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>
-
- 09 7月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
Rather than making the C library search for git every time we want to execute it we now search for the main git wrapper at startup, do symlink resolution, and then always use the absolute path that we found to execute the binary later on. This should save us some cycles, especially on stat challenged systems like Cygwin/Win32. While I was working on this change I also converted all of our existing pipes ([open "| git ..."]) to use two new pipe wrapper functions. These functions take additional options like --nice and --stderr which instructs Tcl to take special action, like running the underlying git program through `nice` (if available) or redirect stderr to stdout for capture in Tcl. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
In some workflows users will want to almost always just create a new local branch that matches a remote branch. In this type of workflow it is handy to have the new branch dialog default to "Match Tracking Branch" and "Starting Revision"-Tracking Branch", with the focus in the branch filter field. This can save users working on this type of workflow at least two mouse clicks every time they create a new local branch or switch to one with a fast-forward. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 06 6月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
If the user clicks on a line region that we haven't yet received an annotation for from git-blame we show them "Loading annotation". But I don't want the user to confuse this loading message with a commit whose first line is "Loading annotation" and think we messed up our display somehow. Since we never use italics for anything else, I'm going with the idea that italic slant can be used to show data is missing/elided out at the time being. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 01 6月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Johannes Sixt pointed out that dropping to 0 lines of context does allow the user to get more fine-grained hunk selection, especially since we don't currently support "highlight and apply (or revert)". Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 29 5月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
Recently git-merge learned to avoid generating the diffstat after a merge by reading the merge.diffstat configuration option. By default this option is assumed to be true, as that is the old behavior. However we can force it to false by setting it as a standard boolean option. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because we now try to automatically guess the library directory in certain installations users may wonder where git-gui is getting its supporting files from. We now display this location in our About dialog, and we also include the location we are getting our Git executables from. Unfortunately users cannot use this 'About git-gui' dialog to troubleshoot library loading problems; the dialog is defined by code that exists in the library directory, creating a catch-22. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
In some workflows it is common for a large number of temporary branches to be created in a remote repository, get fetched to clients that typically only use git-gui, and then later have those branches deleted from the remote repository once they have been fully merged into all destination branches. Users of git-gui would obviously like to have their local tracking branches cleaned up for them, otherwise their local tracking branch namespace would grow out of control. The best known way to remove these tracking branches is to run "git remote prune <remotename>". Even though it is more of a Porcelain command than plumbing I'm invoking it through the UI, because frankly I don't see a reason to reimplement its ls-remote output filtering and config file parsing. A new configuration option (gui.pruneduringfetch) can be used to automatically enable running "git remote prune <remotename>" after the fetch of that remote also completes successfully. This is off by default as it require an additional network connection and is not very fast on Cygwin if a large number of tracking branches have been removed (due to the 2 fork+exec calls per branch). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 08 5月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
I'm finding it difficult to work with a 6,000+ line Tcl script and not go insane while looking for a particular block of code. Since most of the program is organized into different units of functionality and not all users will need all units immediately on startup we can improve things by splitting procs out into multiple files and let auto_load handle things for us. This should help not only to better organize the source, but it may also improve startup times for some users as the Tcl parser does not need to read as much script before it can show the UI. In many cases the user can avoid reading at least half of git-gui now. Unfortunately we now need a library directory in our runtime location. This is currently assumed to be $(sharedir)/git-gui/lib and its expected that the Makefile invoker will setup some sort of reasonable sharedir value for us, or let us assume its going to be $(gitexecdir)/../share. We now also require a tclsh (in TCL_PATH) to just run the Makefile, as we use tclsh to generate the tclIndex for our lib directory. I'm hoping this is not an unncessary burden on end-users who are building from source. I haven't really made any functionality changes here, this is just a huge migration of code from one file to many smaller files. All of the new changes are to setup the library path and install the library files. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-