Per 6eb420ef61 ("git-gui: Always disable the Tcl EOF character when
reading", 2007-07-17), git-gui should disable Tcl's EOF character
detection on all files when on Windows: the default is disabled on all
other platforms (and with Tcl 9.0, is disabled on Windows too). This
EOF character is for compatibility with files / applications written for
file systems that know only the disc sectors allocated, and not the
number of bytes used. This has nothing to do with git.
But, git-gui does not set -eofchar {} on all channels. To avoid any
further leakage, let's just add this to the Windows specific override of
open. This override is needed only as long as Tcl 8.x is in use (Tcl
9.0 makes -eofchar {} default on all platforms).
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
This patch adds the basic support of SHA256 Git repositories.
Most of changes are idiomatic replacement of the hard-coded hash ID
length, but there are subtle things:
* The hash length is determined on startup, and stored in $hashlength
global variable (either 40 or 64).
* The hard-coded "40" are replaced with $hashlength;
for regexp patterns, the ugly string map is used.
* Some code have the fixed numbers like 39 and 45, and those are
replaced with the $hashlength and the offset correction.
* $nullid and $nullid2 are generated for the hash length.
A caveat is that repository picker dialog is performed before
evaluating the repo type, hence $hashlength isn't set there yet.
So the code dealing with the hard-coded "40" are handled differently;
namely, the regexp range is expanded, and the null id is generated
from the HEAD id length locally.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
This addresses CVE-2025-46835, Git GUI can create and overwrite a
user's files:
When a user clones an untrusted repository and is tricked into editing
a file located in a maliciously named directory in the repository, then
Git GUI can create and overwrite files for which the user has write
permission.
* js/fix-open-exec-git:
git-gui: sanitize 'exec' arguments: convert new 'cygpath' calls
git-gui: do not mistake command arguments as redirection operators
git-gui: introduce function git_redir for git calls with redirections
git-gui: pass redirections as separate argument to git_read
git-gui: pass redirections as separate argument to _open_stdout_stderr
git-gui: convert git_read*, git_write to be non-variadic
git-gui: use git_read in githook_read
git-gui: break out a separate function git_read_nice
git-gui: remove option --stderr from git_read
git-gui: sanitize 'exec' arguments: background
git-gui: sanitize 'exec' arguments: simple cases
git-gui: treat file names beginning with "|" as relative paths
git-gui: remove git config --list handling for git < 1.5.3
git-gui: remove HEAD detachment implementation for git < 1.5.3
git-gui: remove Tcl 8.4 workaround on 2>@1 redirection
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Proc git invokes git and collects all output, which is it returns.
We are going to treat command arguments and redirections differently to
avoid passing arguments that look like redirections to the command
accidentally. A few invocations also pass redirection operators as
command arguments deliberately. Rewrite these cases to use a new
function git_redir that takes two lists, one for the regular command
arguments and one for the redirection operations.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
We are going to treat command arguments and redirections differently to
avoid passing arguments that look like redirections to the command
accidentally. To do so, it will be necessary to know which arguments
are intentional redirections. As a preparation, convert git_read,
git_read_nice, and git_write to take just a single argument that is
the command in a list. Adjust all call sites accordingly.
In the future, this argument will be the regular command arguments and
a second argument will be the redirection operations.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
The Tcl 'open' function has a very wide interface. It can open files as
well as pipes to external processes. The difference is made only by the
first character of the file name: if it is "|", a process is spawned.
We have a number of calls of Tcl 'open' that take a file name from the
environment in which Git GUI is running. Be prepared that insane values
are injected. In particular, when we intend to open a file, do not take
a file name that happens to begin with "|" as a request to run a process.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
The commit message is processed to remove unnecessary empty lines.
In particular, it is ensured that the text ends with at most one LF
character. This one is always present, because the Tk text widget
ensures that is present.
However, did not consider that the processed text is written to the
commit message file using `puts`, which also appends a LF character,
so that the final commit message ends with two LF. Trim all trailing
LF characters, and while we are here, use `string trim`, which lets
us remove the leading LF in the same command.
Reported-by: Gareth Fenn <garethfenn@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
This amends 1ae85ff6d (git-gui: strip comments and consecutive empty
lines from commit messages, 2024-08-13) to deal with custom comment
characters/strings.
The magic commentString value "auto" is not handled, because the option
makes no sense to me - it does not support comments in templates and
hook output, and it seems far-fetched that someone would introduce
comments during editing the message.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
We would strip all leading and trailing whitespace, which git commit
does not. Let's be consistent here.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
This is also known as "washing". This is consistent with the behavior of
interactive git commit, which we should emulate as closely as possible
to avoid usability problems. This way commit message templates and
prepare hooks can be used properly, and comments from conflicted rebases
and merges are cleaned up without having to introduce special handling
for them.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
This reverts commit b9a43869c9.
This commit causes breakage on macOS (10.13). It causes errors on
startup and completely breaks the commit functionality. There are two
main problems. First, it uses `string cat` which is not supported on
older Tcl versions. Second, it does a half close of the bidirectional
pipe to git-stripspace which is also not supported on older Tcl
versions.
Reported-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
The comment character is specified by the config variable
'core.commentchar'. Any lines starting with this character is considered
a comment and should not be included in the final commit message.
Teach git-gui to filter out lines in the commit message that start with
the comment character using git-stripspace. If the config is not set,
'#' is taken as the default. Also add a message educating users about
the comment character.
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
Use the file described by commit.template (if set) to show the commit message
template, just like other GUIs.
Signed-off-by: Martin Schön <Martin.Schoen@loewensteinmedical.de>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
Convert author's name and e-mail address from the UTF-8 (or any other)
encoding in load_last_commit function the same way commit message is
converted.
Amending commits in git-gui without such conversion breaks UTF-8
strings. For example, "\305\201ukasz" (as written by git cat-file) becomes
"\303\205\302\201ukasz" in an amended commit.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
Adding _git_ps1() to one's bash prompt displays various repo status
info after each command. After committing a git cherry-pick -n using
git-gui, the prompt still contains the "|CHERRY-PICKING" flag.
Delete the file causing this flag when cleaning up.
Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The commandline is already warning when checking out a detached head.
Since the only thing thats potentially dangerous is to create commits
on a detached head lets warn in case the user is about to do that.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
$s will be referenced in the error message. Which was broken since
"git-gui: Automatically update-index all included files before commit"
(bbe3b3b, 2006-11-16).
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Before calling the post-commit hook, the variable "pc_err" is cleared
while later only "pch_error" is used. "pch_error$cmt_id" only appeared in
"upvar"-Statements (which were changed to "global") and was removed.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As pointed out in msysgit bug #181, when a non-locale encoding is
used for commits, post-commit status messages display the subject
incorrectly. It happens because the file handle is not properly
configured before the subject is read back.
This patch fixes it by factoring out the code that is used to setup
the output handle into a separate function, and calling it from
the reading code.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Robin Rosenberg <robin.rosenberg@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits without an encoding header are supposed to
be encoded in utf8. While this apparently hasn't always
been the case, currently it is the active convention, so
it is better to follow it; otherwise people who have to
use commitEncoding on their machines are unable to read
utf-8 commits made by others.
I also think that it is preferrable to display the warning
about an unsupported value of commitEncoding more prominently,
because this condition may lead to surprising behavior and,
eventually, to loss of data.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
- Make citool return nonzero exit code if it did not commit.
- Add a mode where it does not actually commit and simply
exits with zero code. Commit message is either disabled,
or simply dumped to GITGUI_EDITMSG before exiting.
- Add an option to immediately start it in amend mode.
Rationale:
1) Use 'git citool --nocommit' instead of mergetool in scripts.
2) Use 'git citool --amend' to edit commits while rebasing.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Support _U (local deleted, remote modified) and
UT (file type changed in conflict) modes.
Note that 'file type changed' does not refer to
changes in the executable bit, instead it denotes
replacing a file with a link, or vice versa.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code we use to test if a hook is executable or not differs on
Cygwin from the normal POSIX case. Rather then repeating that for
all three hooks we call in our commit code path we can place the
common logic into a global procedure and invoke it when necessary.
This also lets us get rid of the ugly "|& cat" we were using before
as we can now rely on the Tcl 8.4 feature of "2>@1" or fallback to
the "|& cat" when necessary.
The post-commit hook is now run through the same API, but its outcome
does not influence the commit status. As a result we now show any of
the errors from the post-commit hook in a dialog window, instead of on
the user's tty that was used to launch git-gui. This resolves a long
standing bug related to not getting errors out of the post-commit hook
when launched under git-gui.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Under core Git the git-commit tool will invoke the commit-msg hook
if it exists and is executable to the user running git-commit. As
a hook it has some limited value as it cannot alter the commit, but
it can modify the message the user is attempting to commit. It is
also able to examine the message to ensure it conforms to some local
standards/conventions.
Since the hook takes the name of a temporary file holding the message
as its only parameter we need to move the code that creates the temp
file up earlier in our commit code path, and then pass through that
file name to the latest stage (where we call git-commit-tree). We let
the hook alter the file as it sees fit and we don't bother to look at
its content again until the commit succeeded and we need the subject
for the reflog update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Concatenating commit log messages from multiple commits works better
when all of the commits end with a clean line break.
Its good to be strict in what you create, and lenient in what you
accept, and since we're creating here, we should always try to
Do The Right Thing(tm).
Signed-off-by: Bernt Hansen <bernt@alumni.uwaterloo.ca>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-write-tree fails (such as if the index file is currently
locked and it wants to write to it) we were not getting the error
message as $tree_id was always the empty string so we shortcut
through the catch and never got the output from stderr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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: Shawn O. Pearce <spearce@spearce.org>
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: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Also, the warning message when clicking "Reset" is adapted to
the wording "Reset" rather than a confusion "Cancel commit?".
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
My earlier introduction of the GITGUI_BCK file (which saves the user's
commit message buffer while they are typing it) broke the Quit function.
If the user makes a commit we delete the GITGUI_BCK file; if they then
immediately quit the application we fail to rename the GITGUI_BCK file
to GITGUI_MSG. This is because the file does not exist, but our flag
still says it does. The root cause is we did not unset the flag during
commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A few users have been seeing crashes in Tk when using the undo key
binding to undo the last few keystroke events in the commit buffer.
Unfortunately that means the user loses their commit message and
must start over from scratch when the user restarts the process.
git-gui now saves the user's commit message buffer every couple of
seconds to a temporary file under .git (specifically .git/GITGUI_BCK).
At exit time we rename this file to .git/GITGUI_MSG if there is a
message, the file exists, and it is currently synchronized with the
Tk buffer. Otherwise we do our usual routine of saving the Tk buffer
to .git/GITGUI_MSG and delete .git/GITGUI_BCK, if it exists.
During startup we favor .git/GITGUI_BCK over .git/GITGUI_MSG. This
way a crash doesn't take out the user's message buffer but instead
will cause the user to lose only a few keystrokes. Most people do
not type more than 200 WPM, and with 30 possible saves per minute
we are unlikely to lose more than 7 words.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a essentially a copy of Paul Mackerras encoding support from
gitk. I stole the code from gitk commit fd8ccbec4f, as Paul has
already done all of the hard work setting up this translation table.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows (which includes Cygwin) Tcl defaults to leaving the EOF
character of input file streams set to the ASCII EOF character, but
if that character were to appear in the data stream then Tcl will
close the channel early. So we have to disable eofchar on Windows.
Since the default is disabled on all platforms except Windows, we
can just disable it everywhere to prevent any sort of read problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This cat-file was done on maint, where we did not have git_read
available to us. But here on master we do, so we should make
use of it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
