Add lf_to_nul helper function to test-lib-functions.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.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>
This commit starts the rebase of 8b43994 to 74eeaf7, preparing for a
MinGit-only intermediate release of Git for Windows.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use OpenSSL SHA1 routines rather than builtin block-sha1 routines.
This improves performance on SHA1 operations on Intel processors.
OpenSSL 1.0.2 has made considerable performance improvements and
support the Intel hardware acceleration features. See:
https://software.intel.com/en-us/articles/improving-openssl-performancehttps://software.intel.com/en-us/articles/intel-sha-extensions
To test this I added/staged a single file in a gigantic
repository having a 450MB index file. The code in read-cache.c
verifies the header SHA as it reads the index and computes a new
header SHA as it writes out the new index. Therefore, in this test
the SHA code must process 900MB of data. Testing was done on an
Intel I7-4770 CPU @ 3.40GHz (Intel64, Family 6, Model 60) CPU.
The block-sha1 version averaged 5.27 seconds.
The OpenSSL version averaged 4.50 seconds.
================================================================
$ echo xxx >> project.mk
$ time /e/blk_sha/bin/git.exe add project.mk
real 0m5.207s
user 0m0.000s
sys 0m0.250s
$ echo xxx >> project.mk
$ time /e/blk_sha/bin/git.exe add project.mk
real 0m5.362s
user 0m0.015s
sys 0m0.234s
$ echo xxx >> project.mk
$ time /e/blk_sha/bin/git.exe add project.mk
real 0m5.300s
user 0m0.016s
sys 0m0.250s
$ echo xxx >> project.mk
$ time /e/blk_sha/bin/git.exe add project.mk
real 0m5.216s
user 0m0.000s
sys 0m0.250s
================================================================
$ echo xxx >> project.mk
$ time /e/openssl/bin/git.exe add project.mk
real 0m4.431s
user 0m0.000s
sys 0m0.250s
$ echo xxx >> project.mk
$ time /e/openssl/bin/git.exe add project.mk
real 0m4.478s
user 0m0.000s
sys 0m0.265s
$ echo xxx >> project.mk
$ time /e/openssl/bin/git.exe add project.mk
real 0m4.690s
user 0m0.000s
sys 0m0.250s
$ echo xxx >> project.mk
$ time /e/openssl/bin/git.exe add project.mk
real 0m4.420s
user 0m0.000s
sys 0m0.234s
================================================================
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
A low-level function verify_packfile() was meant to show errors
that were detected without dying itself, but under some conditions
it didn't and died instead, which has been fixed.
* jk/verify-packfile-gently:
verify_packfile: check pack validity before accessing data
"git worktree", even though it used the default_abbrev setting that
ought to be affected by core.abbrev configuration variable, ignored
the variable setting. The command has been taught to read the
default set of configuration variables to correct this.
* jc/worktree-config:
worktree: honor configuration variables
Codepaths that read from an on-disk loose object were too loose in
validating what they are reading is a proper object file and
sometimes read past the data they read from the disk, which has
been corrected. H/t to Gustavo Grieco for reporting.
* jc/verify-loose-object-header:
unpack_sha1_header(): detect malformed object header
streaming: make sure to notice corrupt object
The original command line syntax for "git merge", which was "git
merge <msg> HEAD <parent>...", has been deprecated for quite some
time, and "git gui" was the last in-tree user of the syntax. This
is finally fixed, so that we can move forward with the deprecation.
* rs/git-gui-use-modern-git-merge-syntax:
git-gui: stop using deprecated merge syntax
An author name, that spelled a backslash-quoted double quote in the
human readable part "My \"double quoted\" name", was not unquoted
correctly while applying a patch from a piece of e-mail.
* kd/mailinfo-quoted-string:
mailinfo: unescape quoted-pair in header fields
t5100-mailinfo: replace common path prefix with variable
Almost everybody uses DEFAULT_ABBREV to refer to the default
setting for the abbreviation, but "git blame" peeked into
underlying variable bypassing the macro for no good reason.
* jc/blame-abbrev:
blame: use DEFAULT_ABBREV macro
The "graph" API used in "git log --graph" miscounted the number of
output columns consumed so far when drawing a padding line, which
has been fixed; this did not affect any existing code as nobody
tried to write anything after the padding on such a line, though.
* jk/graph-padding-fix:
graph: fix extra spaces in graph_padding_line
The code that parses the format parameter of for-each-ref command
has seen a micro-optimization.
* sg/ref-filter-parse-optim:
ref-filter: strip format option after a field name only once while parsing
This topic branch works around an out-of-memory bug when the user
specified a format via --date=format:<format> that strftime() does
not like.
Reported by Stefan Naewe.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With the recent update in efee955 (gpg-interface: check gpg signature
creation status, 2016-06-17), we ask GPG to send all status updates to
stderr, and then catch the stderr in an strbuf.
But GPG might fail, and send error messages to stderr. And we simply
do not show them to the user.
Even worse: this swallows any interactive prompt for a passphrase. And
detaches stderr from the tty so that the passphrase cannot be read.
So while the first problem could be fixed (by printing the captured
stderr upon error), the second problem cannot be easily fixed, and
presents a major regression.
So let's just revert commit efee9553a4.
This fixes https://github.com/git-for-windows/git/issues/871
Cc: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This series of branches introduces the git-rebase--helper, a builtin
helping to accelerate the interactive rebase dramatically.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, strftime() does not silently ignore invalid formats, but
warns about them and then returns 0 and sets errno to EINVAL.
Unfortunately, Git does not expect such a behavior, as it disagrees
with strftime()'s semantics on Linux. As a consequence, Git
misinterprets the return value 0 as "I need more space" and grows the
buffer. As the larger buffer does not fix the format, the buffer grows
and grows and grows until we are out of memory and abort.
Ideally, we would switch off the parameter validation just for
strftime(), but we cannot even override the invalid parameter handler
via _set_thread_local_invalid_parameter_handler() using MINGW because
that function is not declared. Even _set_invalid_parameter_handler(),
which *is* declared, does not help, as it simply does... nothing.
So let's just bite the bullet and override strftime() for MINGW and
abort on an invalid format string. While this does not provide the
best user experience, it is the best we can do.
See https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx for more
details.
This fixes https://github.com/git-for-windows/git/issues/863
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add preliminary support for detection of the build plaform, and reporting
of same with the `git version --build-options' command. This can be useful
for bug reporting, to distinguish between 32 and 64-bit builds for
example.
The current implementation can only distinguish between x86 and x86_64.
This will be extended in future patches. In addition, all 32-bit variants
(i686, i586, etc.) are collapsed into `x86'. An example of the output is:
$ git version --build-options
git version 2.9.3.windows.2.826.g06c0f2f
sizeof-long: 4
machine: x86_64
The label of `machine' was chosen so the new information will approximate
the output of `uname -m'.
Signed-off-by: Adric Norris <landstander668@gmail.com>
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>
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 operation has quadratic complexity, which is especially painful
on Windows, where shell scripts are *already* slow (mainly due to the
overhead of the POSIX emulation layer).
Let's reimplement this with linear complexity (using a hash map to
match the commits' subject lines) for the common case; Sadly, the
fixup/squash feature's design neglected performance considerations,
allowing arbitrary prefixes (read: `fixup! hell` will match the
commit subject `hello world`), which means that we are stuck with
quadratic performance in the worst case.
The reimplemented logic also happens to fix a bug where commented-out
lines (representing empty patches) were dropped by the previous code.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `git commit --fixup` command unwraps wrapped onelines when
constructing the commit message, without wrapping the result.
We need to make sure that `git rebase --autosquash` keeps handling such
cases correctly, in particular since we are about to move the autosquash
handling into the rebase--helper.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Note: The original code did not try to skip unnecessary picks of root
commits but punts instead (probably --root was not considered common
enough of a use case to bother optimizing). We do the same, for now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These tests were a bit anal about the *exact* warning/error message
printed by git rebase. But those messages are intended for the *end
user*, therefore it does not make sense to test so rigidly for the
*exact* wording.
In the following, we will reimplement the missing commits check in
the sequencer, with slightly different words.
So let's just test for the parts in the warning/error message that
we *really* care about, nothing more, nothing less.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is crucial to improve performance on Windows, as the speed is now
mostly dominated by the SHA-1 transformation (because it spawns a new
rev-parse process for *every* line, and spawning processes is pretty
slow from Git for Windows' MSYS2 Bash).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
