As suggested by its name, the --smudge option applies the smudge filter
that is currently configured for the specified path.
This feature comes in handy when a 3rd-party tool wants to work with the
contents of files from past revisions as if they had been checked out,
but without detouring via temporary files.
Note that we ensure that symbolic links are unaffected (we know from
looking at the mode).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `rebase` family of Git commands avoid applying patches that were
already integrated upstream. They do that by using the revision walking
option that computes the patch IDs of the two sides of the rebase
(local-only patches vs upstream-only ones) and skipping those local
patches whose patch ID matches one of the upstream ones.
In many cases, this causes unnecessary churn, as already the set of
paths touched by a given commit would suffice to determine that an
upstream patch has no local equivalent.
This hurts performance in particular when there are a lot of upstream
patches, and/or large ones.
Therefore, let's introduce the concept of a "diff-header-only" patch ID,
compare those first, and only evaluate the "full" patch ID lazily.
Please note that in contrast to the "full" patch IDs, those
"diff-header-only" patch IDs are prone to collide with one another, as
adjacent commits frequently touch the very same files. Hence we now
have to be careful to allow multiple hash entries with the same hash.
We accomplish that by using the hashmap_add() function that does not even
test for hash collisions. This also allows us to evaluate the full patch ID
lazily, i.e. only when we found commits with matching diff-header-only
patch IDs.
We add a performance test that demonstrates ~1-6% improvement. In
practice this will depend on various factors such as how many upstream
changes and how big those changes are along with whether file system
caches are cold or warm. As Git's test suite has no way of catching
performance regressions, we also add a regression test that verifies
that the full patch ID computation is skipped when the diff-header-only
computation suffices.
Signed-off-by: Kevin Willford <kcwillford@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will allow a diff patch id to be created using only the header data
so that the contents of the file will not have to be loaded.
Signed-off-by: Kevin Willford <kcwillford@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The cherry_pick_list was looping through the original side checking the
seen indicator and setting the cherry_flag on the commit. If we save
off the commit in the patch_id we can set the cherry_flag on the correct
commit when running through the other side when a patch_id match is found.
Signed-off-by: Kevin Willford <kcwillford@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change will use the hashmap from the hashmap.h to keep track of the
patch_ids that have been encountered instead of using an internal
implementation. This simplifies the implementation of the patch ids.
Signed-off-by: Kevin Willford <kcwillford@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update status manpage to include information about
porcelain v2 format.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Expand porcelain v2 output to include branch and tracking
branch information. This includes the commit id, the branch,
the upstream branch, and the ahead and behind counts.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Collect extra per-file data for porcelain V2 format.
The output of `git status --porcelain` leaves out many
details about the current status that clients might like
to have. This can force them to be less efficient as they
may need to launch secondary commands (and try to match
the logic within git) to accumulate this extra information.
For example, a GUI IDE might want the file mode to display
the correct icon for a changed item (without having to stat
it afterwards).
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update --porcelain argument to take optional version parameter
to allow multiple porcelain formats to be supported in the future.
The token "v1" is the default value and indicates the traditional
porcelain format. (The token "1" is an alias for that.)
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor the API between builtin/commit.c and wt-status.[ch].
Hide the details of the various wt_*status_print() routines inside
wt-status.c behind a single (new) wt_status_print() routine.
Eliminate the switch statements from builtin/commit.c.
Allow details of new status formats to be isolated within wt-status.c
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rename the various wt_status_print*() routines to be
wt_longstatus_print*() to make it clear that these
routines are only concerned with the normal/long
status output and reduce developer confusion as other
status formats are added in the future.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... while waiting for the child process to finish.
The Git wrapper serves, among other things, as git-cmd.exe. In that
role, its primary purpose is to provide an interactive cmd window that
knows where to find Git.
A secondary use of git-cmd.exe is to be able to launch other console
processes that know about Git, e.g. when ConsoleZ wants to call an
interactive Bash (it cannot call git-bash.exe because that would open a
new MinTTY window). To this end, git-cmd.exe supports the --command=...
command-line option. The interactive bash would be called like this:
git-cmd --command=usr\bin\bash.exe -l -i
The command-line arguments after the --command=... options are simply
passed through to the command itself. If no --command=... option is
specified, git-cmd.exe defaults to cmd.exe.
Once git-cmd.exe is launched, it finds the top-level directory of the
Git for Windows installation and then launches the command as a child
process. And this is where things get a little bit tricky: When the user
presses CTRL-C, the cmd window receives WM_KEYDOWN/WM_KEYUP messages
which are then handled by the TranslateMessage function that generates a
CTRL-C event that is sent to the console processes running in the
console window (i.e. both git-cmd.exe and the child process).
If no Console Ctrl Handlers have been registered, the git-cmd.exe
process will simply be terminated, without having waited for the
interactive Bash to quit (it does not quit, of course, because it
handles Ctrl+C by terminating any process launched from within the
Bash). Now both cmd and the Bash compete for user input.
Luckily, the solution is very easy: the Win32 API sports a
SetConsoleCtrlHandler() function to register/unregister Console Ctrl
Handlers. When the NULL pointer is registered as "handler", it "causes
the calling process to ignore CTRL+C input":
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686016.aspx
This is exactly what we need here: while waiting for the child processes
to finish, the git-cmd.exe process itself should not be interruptible by
the user. Immediately after the child process terminates, we unregister
the Console Ctrl Handler.
Note: we need to be careful with changes to the Git wrapper as it serves
many other purposes in addition to git-cmd.exe. For example, it serves
as the cmd\git.exe as well as all of the git-<builtin>.exe stand-ins.
So do we want the same Ctrl+C behavior even in those instances? Yes: If
the user interrupts using Ctrl+C, the child process should terminate
before the Git wrapper.
Also note: We cannot override the Console Ctrl Handler with a function
that simply always returns TRUE: this would prevent the console window
opened via git-cmd.exe from closing, since the Console Ctrl Handler
*also* handles "signals generated by the system when the user closes the
console, logs off, or shuts down the system."
[jes: changed the patch to conform with the surrounding coding style, to
pass NULL as Console Ctrl Handler and unregister it as soon as
appropriate, fixed commit message to be more accurate and informative,
added link to the SetConsoleCtrlHandler() documentation.]
This fixes https://github.com/git-for-windows/git/pull/205
Signed-off-by: Christophe Bucher Developer <christophe.bucher@laposte.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To be precise: when the value of the environment variable is shorter than
its name, we have to move the remaining bytes *after* expanding the
environment variable: we would look for the wrong name otherwise.
When the value is longer than the name, we still need to move the bytes
out of the way first, to avoid overwriting them with the interpolated
text.
This fixes https://github.com/git-for-windows/git/issues/509
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When moving bytes (because the name and the value of the environment
variable to interpolate differ in length), we introduce a variable to
unclutter the code and make it more obvious what is happening.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
After we found the `@@` marker after the key to interpolate, we pretty
much only need the offset *after* the marker. So let's just advance it
instead of adding 2 in many places.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`$HOME/bin/` is quite convenient a place to put user-specific Git
helpers, such as credential or remote helpers.
When run in Git Bash, it is therefore already appended to the PATH;
Let's do the equivalent when run in Git CMD: when `git.exe` is
called, Git is told to look also for scripts and programs in
`$HOME/bin` (this does not modify Git CMD's `PATH`, of course).
This fixes https://github.com/git-for-windows/git/issues/429
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The quoting rules of `cmd.exe` are really, really quirky. In particular,
if there are more than two quotes, the entire set of rules changes. That
is the reason why
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i
works, but
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i "test.sh"
fails with this error message:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
The recommended fix is to pass the /S option to `cmd.exe` and surround
the entire command-line by an extra set of quotes. And here lies the
rub: for that to work, we have to append an extra quote. At the end of
the command-line. *After* the last argument was appended, if any.
This commit supports that use case by introducing the option
"APPEND_QUOTE". The intended usage is to use the following string
resource:
SHOW_CONSOLE=1 APPEND_QUOTE=1
@@COMSPEC@@ /S /C \"\"@@EXEPATH@@\\usr\\bin\\bash.exe\" --login -i
(Note that there are only three quotes on that command-line, the fourth
to be appended due to the `APPEND_QUOTE` setting.)
This is (1/3) to fix https://github.com/git-for-windows/git/issues/396
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper is also used as a redirector for Git for Windows'
bin\bash.exe dropin: for backwards-compatibility, bin\bash.exe exists
and simply sets up the environment variables before executing the
*real* bash.
However, due to our logic to use the directory in which the `.exe`
lives as top-level directory (or one directory below for certain, known
basenames such as `git.exe` and `gitk.exe`), the `PATH` environment
variable was prefixed with the `/bin/bin` and `/bin/mingw/bin`
directories -- which makes no sense.
Instead, let's just auto-detect the top-level directory in the common
case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We should not conflate the 'exepath' with the 'top-level
directory'. The former should be the directory in which the executable
lives while the latter should be the top-level directory ("POSIX root
directory") as far as Git is concerned.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Windows 7 allows users to pin running applications to the task bar. By
setting the application ID, multiple processes can share a single task
bar entry, and this is exactly what we need for `git-bash.exe` which
wants to share the task bar entry with the `mintty.exe` instance it
launches.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of `git-bash.exe` automatically running the Git Bash in the
home directory was to support the start menu item `Git Bash` (which
should not start in C:\Program Files\Git, but in $HOME), and to make
that behavior consistent with double-clicking in `git-bash.exe`
portable Git.
However, it turns out that one of the main use cases of portable Git is
to run the Git Bash in GitHub for Windows, and it should start in the
top-level directory of a given project. Therefore, the concern to keep
double-clicking `git-bash.exe` consistent with the start menu item was
actually unfounded.
As to the start menu item: it can easily be changed to launch
`git-bash.exe` with a command-line option. So let's introduce the
--cd-to-home option for that purpose.
As a bonus, the Git wrapper can now also serve as a drop-in redirector
/bin/bash.exe to provide backwards-compatibility of Git for Windows 2.x
with 1.x: some 3rd-party software expects to find that executable there,
and it also expects it to leave the working directory unchanged.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
By embedding string resources into the Git wrapper executable, it
can be configured to execute custom commands (after setting up the
environment in the way required for Git for Windows to work properly).
This feature is used e.g. for `git-bash.exe` which launches a Bash in
the configured terminal window.
Here, we introduce command-line options to override those string
resources. That way, a user can call `git-bash.exe` (which is a copy of
the Git wrapper with `usr\bin\bash.exe --login -i` embedded as string
resource) with command-line options that will override what command is
run.
ConEmu, for example, might want to call
...\git-bash.exe --needs-console --no-hide --minimal-search-path ^
--command=usr\\bin\\bash.exe --login -i
In particular, the following options are supported now:
--command=<command-line>::
Executes `<command-line>` instead of the embedded string resource
--[no-]minimal-search-path::
Ensures that only `/cmd/` is added to the `PATH` instead of
`/mingw??/bin` and `/usr/bin/`, or not
--[no-]needs-console::
Ensures that there is a Win32 console associated with the spawned
process, or not
--[no-]hide::
Hides the console window, or not
Helped-by: Eli Young <elyscape@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We will enhance the function in the next commit to support @@VAR@@
expansion in the upcoming `--command=<command>` option.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Using different code pages for console input (SetConsoleCP()) and console
output (SetConsoleOutputCP()) doesn't make much sense and may be hazardous
for native Windows programs.
Git uses UTF-8 internally, so it actually needs 'SetConsoleCP(CP_UTF8)'
rather than 'SetConsoleCP(GetACP())'. However, ReadFile() / ReadConsoleA()
are broken with CP_UTF8 (and thus any higher level APIs such as fgetc(),
getchar() etc.). Unicode-aware console input would have to be implemented
via mingw_* wrappers using ReadConsoleW(). As Git typically launches an
editor for anything more complex than ASCII-only, yes/no-style questions,
this is currently not a problem.
Drop 'SetConsoleCP()' from the git-wrapper, so that input and output code
pages stay in sync.
Signed-off-by: Karsten Blees <blees@dcon.de>
When we fall back to starting the Git Bash in the regular Windows
console, we need to show said console's window... So let's introduce yet
another configuration knob for use via string resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With a recent change in Cygwin (which is the basis of the msys2-runtime),
a GUI process desiring to launch an MSys2 executable needs to allocate a
console for the new process (otherwise the process will just hang on
Windows XP). _Git Bash_ is such a GUI process.
While at it, use correct handles when inheriting the stdin/stdout/stderr
handles: `GetStdHandle()` returns NULL for invalid handles, but the
STARTUPINFO must specify `INVALID_HANDLE_VALUE` instead.
Originally, the hope was that only this `NULL` => `INVALID_HANDLE_VALUE`
conversion would be required to fix the Windows XP issue mentioned above
(extensive debugging revealed that starting _Git Bash_ on Windows XP would
yield invalid handles for `stdin` and `stderr`, but *not* for `stdout`).
However, while _Git Bash_ eventually showed a `mintty` when not allocating
a new console, it took around one second to show it, and several seconds
to close it. So let's just include both fixes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With the resource-driven command-line configuration, we introduced the
option to ensure that only the PATH environment variable is edited only
minimally, i.e. only /cmd/ is added (as appropriate for _Git CMD_).
We are about to add another option, so let's refactor the equivalent of
Git's `strip_prefix()` function; It is not *quite* the same because we
have to `memmove()` the remainder to the beginning of the buffer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-wrapper fails to initialize HOME correctly if $HOMEDRIVE$HOMEPATH
points to a disconnected network drive.
Check if the directory exists before using $HOMEDRIVE$HOMEPATH.
Signed-off-by: Karsten Blees <blees@dcon.de>
This change accompanies the `--no-cd` option when configured via
resources. It is required to support `Git Bash Here`: when
right-clicking an icon in the Explorer to start a Bash, the working
directory is actually the directory that is displayed in the Explorer.
That means if the clicked icon actually refers to a directory, the
working directory would be its *parent* directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To avoid that ugly Console window when calling \cmd\git.exe gui...
To avoid confusion with builtins, we need to move the code block
handling gitk (and now git-gui, too) to intercept before git-gui is
mistaken for a builtin.
Unfortunately, git-gui is in libexec/git-core/ while gitk is in bin/,
therefore we need slightly more adjustments than just moving and
augmenting the gitk case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When *Git for Windows* is installed into a directory that has spaces in
it, e.g. `C:\Program Files\Git`, the `git-wrapper` appends this directory
unquoted when fixing up the command line. To resolve this, just quote the
provided `execpath`.
Signed-off-by: nalla <nalla@hamal.uberspace.de>
The idea of having the Git wrapper in the /cmd/ directory is to allow
adding only a *tiny* set of executables to the search path, to allow
minimal interference with other software applications. It is quite
likely, for example, that other software applications require their own
version of zlib1.dll and would not be overly happy to find the version
Git for Windows ships.
The /cmd/ directory also gives us the opportunity to let the Git wrapper
handle the `gitk` script. It is a Tcl/Tk script that is not recognized
by Windows, therefore calling `gitk` in `cmd.exe` would not work, even
if we add all of Git for Windows' bin/ directories.
So let's use the /cmd/ directory instead of adding /mingw??/bin/ and
/usr/bin/ to the PATH when launching Git CMD.
The way we implemented Git CMD is to embed the appropriate command line
as string resource into a copy of the Git wrapper. Therefore we extended
that syntax to allow for configuring a minimal search path.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We recently added the ability to configure copies of the Git wrapper to
launch custom command-lines, configured via plain old Windows resources.
The main user is Git for Windows' `git-bash.exe`, of course. When the
user double-clicks the `git bash` icon, it makes sense to start the Bash
in the user's home directory.
Third-party software, such as TortoiseGit or GitHub for Windows, may
want to start the Git Bash in another directory, though.
Now, when third-party software wants to call Git, they already have to
construct a command-line, and can easily pass a command-line option
`--no-cd` (which this commit introduces), and since that option is not
available when the user double-clicks an icon on the Desktop or in the
Explorer, let's keep the default to switch to the home directory if the
`--no-cd` flag was not passed along.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When we rewrite the command-line to call the *real* Git, we want to skip
the first command-line parameter. The previous code worked in most
circumstances, but was a bit fragile because it assumed that no fancy
quoting would take place.
In the next commit, we will want to have the option to skip more than
just one command-line parameter, so we have to be much more careful with
the command-line handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the meantime, Git for Windows learned to handle those subcommands
quite well itself; There is no longer a need to special-case them in the
wrapper.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In a push to polish Git for Windows more, we are moving away from
scripts toward proper binaries.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper does one thing, and does it well: setting up the
environment required to run Git and its scripts, and then hand off to
another program.
We already do this for the Git executable itself; in Git for Windows'
context, we have exactly the same need also when calling the Git Bash or
Git CMD. However, both are tied to what particular shell environment you
use, though: MSys or MSys2 (or whatever else cunning developers make
work for them). This means that the Git Bash and Git CMD need to be
compiled in the respective context (e.g. when compiling the
mingw-w64-git package in the MSys2 context).
Happily, Windows offers a way to configure compiled executables:
resources. So let's just look whether the current executable has a
string resource and use it as the command-line to execute after the
environment is set up. To support MSys2's Git Bash better (where
`mintty` should, but might not, be available), we verify whether the
specified executable exists, and keep looking for string resources if it
does not.
For even more flexibility, we expand environment variables specified as
`@@<VARIABLE-NAME>@@`, and for convenience `@@EXEPATH@@` expands into
the directory in which the executable resides.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Otherwise the output of Git commands cannot be caught by, say, Git GUI
(because it is running detached from any console, which would make
`git.exe` inherit the standard handles implicitly).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We are about to use the Git wrapper to call the Git Bash of Git for
Windows. All the wrapper needs to do for that is to set up the
environment variables, use the home directory as working directory and
then hand off to a user-specified command-line.
We prepare the existing code for this change by introducing flags to set
up the environment variables, to launch a non-Git program, and to use
the home directory as working directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The original purpose of the Git wrapper is to run from inside Git for
Windows' /cmd/ directory, to allow setting up some environment variables
before Git is allowed to take over.
Due to differences in the file system layout, MSys2 requires some
changes for that to work.
In addition, we must take care to set the `MSYSTEM` environment variable
to `MINGW32` or `MINGW64`, respectively, to allow MSys2 to be configured
correctly in case Git launches a shell or Perl script.
We also need to change the `TERM` variable to `cygwin` instead of
`msys`, otherwise the pager `less.exe` (spawned e.g. by `git log`) will
simply crash with a message similar to this one:
1 [main] less 9832 cygwin_exception::open_stackdumpfile:
Dumping stack trace to less.exe.stackdump
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This reduces the disk footprint of a full Git for Windows setup
dramatically because on Windows, one cannot assume that hard links are
supported.
The net savings are calculated easily: the 32-bit `git.exe` file weighs
in with 7662 kB while the `git-wrapper.exe` file (modified to serve as a
drop-in replacement for builtins) weighs a scant 21 kB. At this point,
there are 109 builtins which results in a total of 813 MB disk space
being freed up by this commit.
Yes, that is really more than half a gigabyte.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
