When Git for Windows was still based on MSys1, we had no gettext, ergo
no msgfmt, either. Therefore, we introduced a small and simple Tcl
script to perform the same task.
However, with MSys2, we no longer need that because we have a proper
msgfmt executable. Plus, the po2msg.sh script somehow manages to hang
when run in parallel in Git for Windows' SDK (symptom: the Continuous
Testing tasks timing out).
Two reasons to use real msgfmt.exe instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
_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>
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: Alexey Astakhov <asstv7@gmail.com>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Commit 7e71adc77f 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: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Cloud Chou <515312382@qq.com>
Original-test-by: Cloud Chou <515312382@qq.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Cloud Chou <515312382@qq.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Karsten Blees <blees@dcon.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Commit b5f325c updated to use the newer merge syntax but continue to
support older versions of git.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Mark string "$hook hook failed:" in lib/error.tcl for translation.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: 31bb1d1 ("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.htm
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Mark command-line "usage:" string for translation in git-gui.sh.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Alex Riesen <alexander.riesen@cetitec.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Alex Riesen <alexander.riesen@cetitec.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: yaras <yaras6@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Elia Pinto <gitter.spiros@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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/448
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
MSys2 might *look* like Cygwin, but it is *not* Cygwin... Unless it
is run with `MSYSTEM=MSYS`, that is.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Pat Thoyts <patthoyts@users.sourceforge.net>
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: Pat Thoyts <patthoyts@users.sourceforge.net>
Mark strings for translation in lib/index.tcl that were seemingly
left behind by 700e560 ("git-gui: Mark forgotten strings for
translation.", 2008-09-04) which marks string in do_revert_selection
procedure.
These strings are passed to unstage_help and add_helper procedures.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Starting with v2.5.0 git merge can handle FETCH_HEAD internally and
warns when it's called like 'git merge <message> HEAD <commit>' because
that syntax is deprecated. Use this feature in git-gui and get rid of
that warning.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As of v2.9.0, `git commit-tree` no longer heeds the `commit.gpgsign`
config setting. This broke committing with GPG signature in Git GUI.
This fixes https://github.com/git-for-windows/git/issues/850
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git commit --amend preserves the author details unless --reset-author is
given.
git-gui discards the author details on amend.
Fix by reading the author details along with the commit message, and
setting the appropriate environment variables required for preserving
them.
Reported long ago in the mailing list[1].
[1] http://article.gmane.org/gmane.comp.version-control.git/243921
Signed-off-by: Orgad Shaneh <orgad.shaneh@audiocodes.com>
ALL_LIBFILES uses wildcard, which provides the result in directory
order. This order depends on the underlying filesystem on the
buildhost. To get reproducible builds it is required to sort such list
before using them.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
