- 10 1月, 2018 3 次提交
-
-
由 Johannes Schindelin 提交于
If there is nothing to stage, there is nothing to stage. Let's not try to, even if the file list contains nothing at all. This fixes https://github.com/git-for-windows/git/issues/1075Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
Previously unstaged files can be staged by clicking on them and then pressing Ctrl+T. Conveniently, the next unstaged file is selected automatically so that the unstaged files can be staged by repeatedly pressing Ctrl+T. When a user hits Ctrl+T one time too many, though, Git GUI used to throw this exception: expected number but got "" expected number but got "" while executing "expr {int([lindex [$w tag ranges in_diff] 0])}" (procedure "toggle_or_diff" line 13) invoked from within "toggle_or_diff toggle .vpane.files.workdir.list " (command bound to event) Let's just avoid that by skipping the operation when there are no more files to stage. This fixes https://github.com/git-for-windows/git/issues/1060Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
When a 1-line file is augmented by a second line, and the user tries to stage that single line via the "Stage Line" context menu item, we do not want to see "apply: corrupt patch at line 5". The reason for this error was that the hunk header looks like this: @@ -1 +1,2 @@ but the existing code expects the original range always to contain a comma. This problem is easily fixed by cutting the string "1 +1,2" (that Git GUI formerly mistook for the starting line) at the space. This fixes https://github.com/git-for-windows/git/issues/515Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 3月, 2017 1 次提交
-
-
由 Pat Thoyts 提交于
Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
- 21 1月, 2017 4 次提交
-
-
由 Philip Oakley 提交于
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: NPhilip Oakley <philipoakley@iee.org>
-
由 Philip Oakley 提交于
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: NPhilip Oakley <philipoakley@iee.org>
-
由 Philip Oakley 提交于
_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: NPhilip Oakley <philipoakley@iee.org>
-
由 Philip Oakley 提交于
The git gui's recent repo list may become contaminated with duplicate entries. The git gui would barf when attempting to remove one entry. Remove them all - there is no option within 'git config' to selectively remove one of the entries. This issue was reported on the 'Git User' list (https://groups.google.com/forum/#!topic/git-users/msev4KsQGFc, Warning: gui.recentrepo has multiply values while executing). And also by zosrothko as a Git-for-Windows issue https://github.com/git-for-windows/git/issues/1014. On startup the gui checks that entries in the recentrepo list are still valid repos and deletes thoses that are not. If duplicate entries are present the 'git config --unset' will barf and this prevents the gui from starting. Subsequent patches fix other parts of recentrepo logic used for syncing internal lists with the external .gitconfig. Reported-by: NAlexey Astakhov <asstv7@gmail.com> Signed-off-by: NPhilip Oakley <philipoakley@iee.org>
-
- 20 10月, 2016 6 次提交
-
-
由 Pat Thoyts 提交于
Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Pat Thoyts 提交于
-
由 Alexander Shopov 提交于
Signed-off-by: NAlexander Shopov <ash@kambanaria.org> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Alexander Shopov 提交于
Signed-off-by: NAlexander Shopov <ash@kambanaria.org> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Pat Thoyts 提交于
-
由 Pat Thoyts 提交于
-
- 07 10月, 2016 1 次提交
-
-
由 Pat Thoyts 提交于
Commit 7e71adc7 fixes a problem with git-gui failing to pick up the original author identity during a commit --amend operation. However, the new author details then become persistent for the remainder of the session. This commit fixes this by ensuring the environment variables are reset and the author information reset once the commit is completed. The relevant changes were reworked to reduce global variables. Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
- 06 10月, 2016 2 次提交
-
-
由 Karsten Blees 提交于
If we use 'eval exec $opt $cmdp $args' to execute git command, tcl engine will convert the output of the git comand with the rule system default code page to unicode. But cp936 -> unicode conversion implicitly done by exec is not reversible. So we have to use git_read instead. Bug report and an original reproducer by Cloud Chou: https://github.com/msysgit/git/issues/302 Cloud Chou find the reason of the bug. Thanks-to: Johannes Schindelin <johannes.schindelin@gmx.de> Thanks-to: Pat Thoyts <patthoyts@users.sourceforge.net> Reported-by: NCloud Chou <515312382@qq.com> Original-test-by: NCloud Chou <515312382@qq.com> Signed-off-by: NKarsten Blees <blees@dcon.de> Signed-off-by: NCloud Chou <515312382@qq.com> Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Karsten Blees 提交于
Assumes file names in git tree objects are UTF-8 encoded. On most unix systems, the system encoding (and thus the TCL system encoding) will be UTF-8, so file names will be displayed correctly. On Windows, it is impossible to set the system encoding to UTF-8. Changing the TCL system encoding (via 'encoding system ...', e.g. in the startup code) is explicitly discouraged by the TCL docs. Change git-gui functions dealing with file names to always convert from and to UTF-8. Signed-off-by: NKarsten Blees <blees@dcon.de> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
- 05 10月, 2016 3 次提交
-
-
由 Pat Thoyts 提交于
-
由 Dimitriy Ryazantcev 提交于
Signed-off-by: NDimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Pat Thoyts 提交于
Commit b5f325cb updated to use the newer merge syntax but continue to support older versions of git. Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
- 04 10月, 2016 16 次提交
-
-
由 Pat Thoyts 提交于
-
由 Vasco Almeida 提交于
Mark string "$hook hook failed:" in lib/error.tcl for translation. Signed-off-by: NVasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Vasco Almeida 提交于
Fix wrong use of append command in strings marked for translation. According to Tcl/Tk Documentation [1], append varName ?value value value ...? appends all value arguments to the current value of variable varName. This means that append "[appname] ([reponame]): " [mc "File Viewer"] is setting a variable named "[appname] ([reponame]): " to the output of [mc "File Viewer"], rather than returning the concatenation of both expressions as one might expect. The format for some strings enables, for instance, a French translator to translate like "%s (%s) : Create Branch" (space before colon). Conversely, strings already translated will be marked as fuzzy and the translator must update them herself. For some cases, use alternative way for concatenation instead of using strcat procedure defined in git-gui.sh. Reference: 31bb1d1b ("git-gui: Paper bag fix missing translated strings", 2007-09-14) fixes the same issue slightly differently. [1] http://www.tcl.tk/man/tcl/TclCmd/append.htmSigned-off-by: NVasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Vasco Almeida 提交于
Mark command-line "usage:" string for translation in git-gui.sh. Signed-off-by: NVasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Vasco Almeida 提交于
Internationalize use of colon punctuation ':' in options window, windows titles, database statistics window. Some languages might use a different style, for instance French uses "User Name :" (space before colon). Signed-off-by: NVasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Pat Thoyts 提交于
-
由 Pat Thoyts 提交于
-
由 Pat Thoyts 提交于
-
由 Alex Riesen 提交于
It is very confusing that the file which diff is displayed is marked as selected, but it is not in fact selected (that means the array of selected files does not include the file in question). Fixing this also improves the use of $FILENAMES in custom defined tools: one does not have to click the file in the list to make it selected. Signed-off-by: NAlex Riesen <alexander.riesen@cetitec.com> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Alex Riesen 提交于
This adds a FILENAMES environment variable, which contains the repository pathnames of all selected files the list. The variable contains the names separated by LF (\n, \x0a). If the file names contain LF characters, the tool command might be unable to unambiguously split the value of $FILENAME into the separate names. Note that the file marked and diffed immediately after starting the GUI up, is not actually selected. One must click on it once to really select it. Signed-off-by: NAlex Riesen <alexander.riesen@cetitec.com> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 yaras 提交于
This fix refers https://github.com/git-for-windows/git/issues/664 After `git merge --squash` git creates .git/SQUASH_MSG (UTF-8 encoded) which contains squashed commits. When run `git gui` it copies SQUASH_MSG to PREPARE_COMMIT_MSG, but without honoring UTF-8. This leads to encoding problems on `git gui` commit prompt. The same applies on git cherry-pick conflict, where MERGE_MSG is created and then is copied to PREPARE_COMMIT_MSG. In both cases PREPARE_COMMIT_MSG must be configured to store data in UTF-8. Signed-off-by: Nyaras <yaras6@gmail.com> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Elia Pinto 提交于
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: NElia Pinto <gitter.spiros@gmail.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Pat Thoyts 提交于
-
由 Pat Thoyts 提交于
-
由 Pat Thoyts 提交于
-
由 Pat Thoyts 提交于
-
- 03 10月, 2016 2 次提交
-
-
由 Pat Thoyts 提交于
When calling `Repository>Create Desktop Shortcut`, Git GUI assumes that it is okay to call `wish.exe` directly on Windows. However, in Git for Windows 2.x' context, that leaves several crucial environment variables uninitialized, resulting in a shortcut that does not work. To fix those environment variable woes, Git for Windows comes with a convenient `git-gui.exe`, so let's just use it when it is available. This fixes https://github.com/git-for-windows/git/issues/448Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Pat Thoyts 提交于
MSys2 might *look* like Cygwin, but it is *not* Cygwin... Unless it is run with `MSYSTEM=MSYS`, that is. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
- 02 10月, 2016 2 次提交
-
-
由 Pat Thoyts 提交于
Tab order follows widget creation order (and Z-order) so amend this to match the layout more logically. For keyboard selection a highlight around the selected text widget is useful. Customized on Windows themed Tk to follow the native theme more closely with a custom EntryFrame style. Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-
由 Pat Thoyts 提交于
Keyboard focus was restricted to the commit message widget and users were forced to use the mouse to select files in the workdir widget and only then could use a key combination to stage the file. It is now possible to use key navigation (Ctrl-Tab, arrow keys and Ctrl-T or Ctrl-U) to stage and unstage files. Suggested by @koppor in git-for-window/git issue #859 Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
-