This topic branch adds the support for --filters (TAFKA --smudge) and
--path (TAFKA --use-path).
While at it, we also add support for --filters/--textconv in --batch mode
(the input lines now need to contain the path in addition to the object
name, separated by a single white space character).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This reverts commit 7576a30b53, reversing
changes made to 6de9d8ad27.
The patch series has been sent upstream and modifications were necessary
as a consequence. We will merge the new version of the patch series in
one moment.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For backwards compatibility with Git for Windows v2.9.3, we need to
support the --smudge and --use-path options (the options are now called
--filters and --path).
Let's do that, but print out a honking warning that these options are
deprecated. The plan is to drop them in v2.10.0 anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With this patch, --batch can be combined with --textconv or --filters.
For this to work, the input needs to have the form
<object name><single white space><path>
so that the filters can be chosen appropriately.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There are circumstances when it is relatively easy to figure out the
object name for a given path, but not the name of the containing tree.
For example, when looking at a diff generated by Git, the object names
are recorded, but not the revision. As a matter of fact, the revisions
from which the diff was generated may not even exist locally.
In such a case, the user would have to generate a fake revision just to
be able to use --textconv or --filters.
Let's simplify this dramatically, because we do not really need that
revision at all: all we care about is that we know the path. In the
scenario described above, we do know the path, and we just want to
specify it separately from the object name.
Example usage:
git cat-file --textconv --path=main.c 0f1937fd
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The --filters option applies the convert_to_working_tree() filter for
the path when showing the contents of a regular file blob object.
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.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It has been reported that core.hideDotFiles=false stopped working...
This topic branch fixes it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This branch allows third-party tools to call `git status
--no-lock-index` to avoid lock contention with the interactive Git usage
of the actual human user.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch adds support to cat-file to apply the smudge filter
(if any) when showing blobs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This fixes an issue where the Git wrapper would terminate upon Ctrl+C,
even in the case when its child process would *not* terminate.
Note: while the original intention was to fix running Git Bash in
ConsoleZ, the bug fix applies also to running
C:\Program Files\Git\bin\bash -l -i
in a cmd window.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was a bug in the wrapper where it would interpolate incorrectly if
the name of the environment variable to expand was longer than the value.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch adds the --command=<command> option that allows
starting the Git Bash (or Git CMD) with different terminal emulators
than the one encoded via embedded string resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use msysGit's `git-wrapper` instead of the builtins. This works around
two issues:
- when the file system does not allow hard links, we would waste over
800 megabyte by having 109 copies of a multi-megabyte executable
- even when the file system allows hard links, the Windows Explorer
counts the disk usage as if it did not. Many users complained about
Git for Windows using too much space (when it actually did not). We
can easily avoid those user complaints by merging this branch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is a brown paper bag. When adding the tests, we actually failed
to verify that the config variable is heeded in git-init at all. And
when changing the original patch that marked the .git/ directory as
hidden after reading the config, it was lost on this developer that
the new code would use the hide_dotfiles variable before the config
was read.
The fix is obvious: read the (limited, pre-init) config *before*
creating the .git/ directory.
This fixes https://github.com/git-for-windows/git/issues/789
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When a third-party tool periodically runs `git status` in order to keep
track of the state of the working tree, it is a bad idea to lock the
index: it might interfere with interactive commands executed by the
user, e.g. when the user wants to commit files.
Let's introduce the option `--no-lock-index` to prevent such problems.
The idea is that the third-party tool calls `git status` with this
option, preventing it from ever updating the index.
The downside is that the periodic `git status` calls will be a little
bit more wasteful because they may have to refresh the index repeatedly,
only to throw away the updates when it exits. This cannot really be
helped, though, as tools wanting to get a periodic update of the status
have no way to predict when the user may want to lock the index herself.
Note that the regression test added in this commit does not *really*
verify that no index.lock file was written; that test is not possible in
a portable way. Instead, we verify that .git/index is rewritten *only*
when `git status` is run without `--no-lock-index`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There are circumstances when it is relatively easy to figure out the
object name for a given path, but not the revision. For example, when
looking at a diff generated by Git, the object names are recorded, but
not the revision. As a matter of fact, the revisions from which the diff
was generated may not even exist locally.
In such a case, the user would have to generate a fake revision just to
be able to use --textconv or --smudge.
Let's simplify this dramatically, because we do not really need that
revision at all: all we care about is that we know the path. In the
scenario described above, we do know the path, and we just want to
specify it separately from the object name.
Example usage:
git cat-file --textconv --use-path=main.c 0f1937fd
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
