"git status --branch --short" accessed beyond the constant string
"HEAD", which has been corrected.
* rs/wt-status-detached-branch-fix:
wt-status: use skip_prefix() to get rid of magic string length constants
wt-status: don't skip a magical number of characters blindly
wt-status: avoid building bogus branch name with detached HEAD
wt-status: exit early using goto in wt_shortstatus_print_tracking()
t7060: add test for status --branch on a detached HEAD
"git --literal-pathspecs add -u/-A" without any command line
argument misbehaved ever since Git 2.0.
* jc/add-u-A-default-to-top:
add: simplify -u/-A without pathspec
Merging a branch that removes a path and another that changes the
mode bits on the same path should have conflicted at the path, but
it didn't and silently favoured the removal.
* jk/delete-modechange-conflict:
merge: detect delete/modechange conflict
t6031: generalize for recursive and resolve strategies
t6031: move triple-rename test to t3030
It was not possible to use a repository-lookalike created by "git
worktree add" as a local source of "git clone".
* nd/clone-linked-checkout:
clone: better error when --reference is a linked checkout
clone: allow --local from a linked checkout
enter_repo: allow .git files in strict mode
enter_repo: avoid duplicating logic, use is_git_directory() instead
t0002: add test for enter_repo(), non-strict mode
path.c: delete an extra space
"git merge-file" tried to signal how many conflicts it found, which
obviously would not work well when there are too many of them.
* jk/merge-file-exit-code:
merge-file: clamp exit code to maximum 127
The submodule code has been taught to work better with separate
work trees created via "git worktree add".
* mk/submodule-gitdir-path:
path: implement common_dir handling in git_pathdup_submodule()
submodule refactor: use strbuf_git_path_submodule() in add_submodule_odb()
Work around "git p4" failing when the P4 depot records the contents
in UTF-16 without UTF-16 BOM.
* ls/p4-translation-failure:
git-p4: handle "Translation of file content failed"
git-p4: add test case for "Translation of file content failed" error
Recent update to "rebase -i" that tries to sanity check the edited
insn sheet before it uses it has become too picky on Windows where
CRLF left by the editor is turned into a trailing CR on the line
read via the "read" built-in command.
* gr/rebase-i-drop-warn:
rebase-i: work around Windows CRLF line endings
t3404: "rebase -i" gets broken when insn sheet uses CR/LF line endings
"git clone --dissociate" runs a big "git repack" process at the
end, and it helps to close file descriptors that are open on the
packs and their idx files before doing so on filesystems that
cannot remove a file that is still open.
* js/clone-dissociate:
clone --dissociate: avoid locking pack files
sha1_file.c: add a function to release all packs
sha1_file: consolidate code to close a pack's file descriptor
t5700: demonstrate a Windows file locking issue with `git clone --dissociate`
Correct "git p4 --detect-labels" so that it does not fail to create
a tag that points at a commit that is also being imported.
* ld/p4-import-labels:
git-p4: fix P4 label import for unprocessed commits
git-p4: do not terminate creating tag for unknown commit
git-p4: failing test for ignoring invalid p4 labels
Prepare for Git on-disk repository representation to undergo
backward incompatible changes by introducing a new repository
format version "1", with an extension mechanism.
* jk/repository-extension:
introduce "preciousObjects" repository extension
introduce "extensions" form of core.repositoryformatversion
If we're on a detached HEAD then wt_shortstatus_print_tracking() takes
the string "HEAD (no branch)", translates it, skips the first eleven
characters and passes the result to branch_get(), which returns a bogus
result and accesses memory out of bounds in order to produce it.
Somehow stat_tracking_info(), which is passed that result, does the
right thing anyway, i.e. it finds that there is no base.
Avoid the bogus results and memory accesses by checking for HEAD first
and exiting early in that case. This fixes t7060 with --valgrind.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test fails when run under Valgrind because branch_get() gets passed
a bogus branch name pointer:
==62831== Invalid read of size 1
==62831== at 0x4F76AE: branch_get (remote.c:1650)
==62831== by 0x53499E: wt_shortstatus_print_tracking (wt-status.c:1654)
==62831== by 0x53499E: wt_shortstatus_print (wt-status.c:1706)
==62831== by 0x428D29: cmd_status (commit.c:1384)
==62831== by 0x405D6D: run_builtin (git.c:350)
==62831== by 0x405D6D: handle_builtin (git.c:536)
==62831== by 0x404F10: run_argv (git.c:582)
==62831== by 0x404F10: main (git.c:690)
==62831== Address 0x5e89b0b is 6 bytes after a block of size 5 alloc'd
==62831== at 0x4C28C4F: malloc (vg_replace_malloc.c:299)
==62831== by 0x59579E9: strdup (strdup.c:42)
==62831== by 0x52E108: xstrdup (wrapper.c:43)
==62831== by 0x5322A6: wt_status_prepare (wt-status.c:130)
==62831== by 0x4276E0: status_init_config (commit.c:184)
==62831== by 0x428BB8: cmd_status (commit.c:1350)
==62831== by 0x405D6D: run_builtin (git.c:350)
==62831== by 0x405D6D: handle_builtin (git.c:536)
==62831== by 0x404F10: run_argv (git.c:582)
==62831== by 0x404F10: main (git.c:690)
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git-merge-file is documented to return one of three exit
codes:
- zero means the merge was successful
- a negative number means an error occurred
- a positive number indicates the number of conflicts
Unfortunately, this all gets stuffed into an 8-bit return
code. Which means that if you have 256 conflicts, this wraps
to zero, and the merge appears to succeed (and commits a
blob full of conflict-marker cruft!).
This patch clamps the return value to a maximum of 127,
which we should be able to safely represent everywhere. This
also leaves 128-255 for other values. Shells (and some parts
of git) will typically represent signal death as 128 plus
the signal number. And negative values are typically coerced
to an 8-bit unsigned value (so "return -1" ends up as 255).
Technically negative returns have the same problem (e.g.,
"-256" wraps back to 0), but this is not a problem in
practice, as the only negative value we use is "-1".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Editors on Windows can and do save text files with CRLF line
endings, which is the convention on the platform. We are seeing
reports that the "read" command in a port of bash to the environment
however does not strip the CRLF at the end, not adjusting for the
same convention on the platform.
This breaks the recently added sanity checks for the insn sheet fed
to "rebase -i"; instead of an empty line (hence nothing in $command),
the script was getting a lone CR in there.
Special case a lone CR and treat it the same way as an empty line to
work this around.
This patch (also) passes the test with Git for Windows, where the
issue was seen first.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If one side deletes a file and the other changes its
content, we notice and report a conflict. However, if
instead of changing the content, we change only the mode,
the merge does not notice (and the mode change is silently
dropped).
The trivial index merge notices the problem and correctly
leaves the conflict in the index, but both merge-recursive
and merge-one-file will silently resolve this in favor of
the deletion. In many cases that is a sane resolution, but
we should be punting to the user whenever there is any
question. So let's detect and treat this as a conflict (in
both strategies).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This script tests the filemode handling of merge-recursive,
but we do not test the same thing for merge-resolve. Let's
generalize the script a little:
1. Break out the setup steps for each test into a separate
snippet.
2. For each test, run it twice; once with "-s recursive"
and once with "-s resolve". We can avoid repeating
ourselves by adding a function.
3. Since we have a nice abstracted function, we can make
our tests more thorough by testing both directions
(change on "ours" versus "theirs").
This improves our test coverage, and will make this the
place to add more tests related to merging mode changes.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The t6031 test was introduced to check filemode handling of
merge-recursive. Much later, an unrelated test was tacked on
to look at renames and d/f conflicts. This test does not
depend on anything that happened before (it actually blows
away any existing content in the test repo). Let's move it
to t3030, where there are more related tests.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since Git 2.0, "add -u" and "add -A" run from a subdirectory without
any pathspec mean "everything in the working tree" (before 2.0, they
were limited to the current directory). The limiting to the current
directory was implemented by inserting "." to the command line when
the end user did not give us any pathspec. At 2.0, we updated the
code to insert ":/" (instead of '.') to consider everything from the
top-level, by using a pathspec magic "top".
The call to parse_pathspec() using the command line arguments is,
however, made with PATHSPEC_PREFER_FULL option since 5a76aff1 (add:
convert to use parse_pathspec, 2013-07-14), which predates Git 2.0.
In retrospect, there was no need to turn "adding . to limit to the
directory" into "adding :/ to unlimit to everywhere" in Git 2.0;
instead we could just have done "if there is no pathspec on the
command line, just let it be". The parse_pathspec() then would give
us a pathspec that matches everything and all is well.
Incidentally such a simplification also fixes a corner case bug that
stems from the fact that ":/" does not necessarily mean any magic.
A user would say "git --literal-pathspecs add -u :/" from the
command line when she has a directory ':' and wants to add
everything in it (and she knows that her :/ will be taken as
'everything under the sun' magic pathspec unless she disables the
magic with --literal-pathspecs). The internal use of ':/' would
behave the same way as such an explicitly given ":/" when run with
"--literal-pathspecs", and will not add everything under the sun as
the code originally intended.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git gc" used to barf when a symbolic ref has gone dangling
(e.g. the branch that used to be your upstream's default when you
cloned from it is now gone, and you did "fetch --prune").
* js/gc-with-stale-symref:
pack-objects: do not get distracted by broken symrefs
gc: demonstrate failure with stale remote HEAD
A recent "filter-branch --msg-filter" broke skipping of the commit
object header, which is fixed.
* jk/filter-branch-use-of-sed-on-incomplete-line:
filter-branch: remove multi-line headers in msg filter
Dirty the test worktree's root directory, as the test expects.
When testing the untracked-cache, we previously assumed that checking
out master would be sufficient to mark the mtime of the worktree's
root directory as racily-dirty. But sometimes, the checkout would
happen at 12345.999 seconds and the status at 12346.001 seconds,
meaning that the worktree's root directory would not be racily-dirty.
And since it was not truly dirty, occasionally the test would fail.
By making the root truly dirty, the test will always succeed.
Tested by running a few hundred times.
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were some classes of errors that "git fsck" diagnosed to its
standard error that did not cause it to exit with non-zero status.
* jc/fsck-dropped-errors:
fsck: exit with non-zero when problems are found
Performance-measurement tests did not work without an installed Git.
* sb/perf-without-installed-git:
t/perf: make runner work even if Git is not installed
After "git checkout --detach", "git status" reported a fairly
useless "HEAD detached at HEAD", instead of saying at which exact
commit.
* mm/detach-at-HEAD-reflog:
status: don't say 'HEAD detached at HEAD'
t3203: test 'detached at' after checkout --detach
"git rebase -i" had a minor regression recently, which stopped
considering a line that begins with an indented '#' in its insn
sheet not a comment, which is now fixed.
* gr/rebase-i-drop-warn:
rebase-i: loosen over-eager check_bad_cmd check
rebase-i: explicitly accept tab as separator in commands
The way how --ref/--notes to specify the notes tree reference are
DWIMmed was not clearly documented.
* jk/notes-dwim-doc:
notes: correct documentation of DWIMery for notes references
The ssh transport, just like any other transport over the network,
did not clear GIT_* environment variables, but it is possible to
use SendEnv and AcceptEnv to leak them to the remote invocation of
Git, which is not a good idea at all. Explicitly clear them just
like we do for the local transport.
* jk/connect-clear-env:
git_connect: clarify conn->use_shell flag
git_connect: clear GIT_* environment for ssh
"git blame --first-parent v1.0..v2.0" was not rejected but did not
limit the blame to commits on the first parent chain.
* jk/blame-first-parent:
blame: handle --first-parent
df062010 (filter-branch: avoid passing commit message through sed)
introduced a regression when filtering commits with multi-line headers,
if the header contains a blank line. An example of this is a gpg-signed
commit:
$ git cat-file commit signed-commit
tree 3d4038e029712da9fc59a72afbfcc90418451630
parent 110eac945dc1713b27bdf49e74e5805db66971f0
author A U Thor <author@example.com> 1112912413 -0700
committer C O Mitter <committer@example.com> 1112912413 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlYXADwACgkQE7b1Hs3eQw23CACgldB/InRyDgQwyiFyMMm3zFpj
pUsAnA+f3aMUsd9mNroloSmlOgL6jIMO
=0Hgm
-----END PGP SIGNATURE-----
Adding gpg
As a consequence, "filter-branch --msg-filter cat" (which should leave the
commit message unchanged) spills the signature (after the internal blank
line) into the original commit message.
The reason is that although the signature is indented, making the line a
whitespace only line, the "read" call is splitting the line based on
the shell's IFS, which defaults to <space><tab><newline>. The leading
space is consumed and $header_line is empty, causing the "skip header
lines" loop to exit.
The rest of the commit object is then re-used as the rewritten commit
message, causing the new message to include the signature of the
original commit.
Set IFS to an empty string for the "read" call, thus disabling the word
splitting, which causes $header_line to be set to the non-empty value ' '.
This allows the loop to fully consume the header lines before
emitting the original, intact commit message.
[jc: this is literally based on MJG's suggestion]
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: James McCoy <vega.james@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is quite possible for, say, a remote HEAD to become broken, e.g.
when the default branch was renamed.
We should still be able to pack our objects when such a thing happens;
simply ignore broken symrefs (because they cannot matter for the packing
process anyway).
This fixes https://github.com/git-for-windows/git/issues/423
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When `git clone` is asked to dissociate the repository from the
reference repository whose objects were used, it is quite possible that
the pack files need to be repacked. In that case, the pack files need to
be deleted that were originally hard-links to the reference repository's
pack files.
On platforms where a file cannot be deleted if another process still
holds a handle on it, we therefore need to take pains to release all
pack files and indexes before dissociating.
This fixes https://github.com/git-for-windows/git/issues/446
The test case to demonstrate the breakage technically does not need to
be run on Linux or MacOSX. It won't hurt, either, though.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Linked checkouts are known under the name worktree, now. Rename the test
accordingly.
Specifically, this avoids the confusion that t2026 is actually not about
pruning in or with linked checkouts aka worktress but about pruning
worktrees, i.e. about "git worktree prune" rather than "git prune".
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
804098bb (git rebase -i: add static check for commands and SHA-1,
2015-06-29) tried to check all insns before running any in the todo
list, but it did so by implementing its own parser that is a lot
stricter than necessary. We used to allow lines that are indented
(including comment lines), and we used to allow a whitespace between
the insn and the commit object name to be HT, among other things,
that are flagged as an invalid line by mistake.
Fix this by using the same tokenizer that is used to parse the todo
list file in the new check.
Whether it's a good thing to accept indented comments is
debatable (other commands like "git commit" do not accept them), but we
already accepted them in the past, and some people and scripts rely on
this behavior. Also, a line starting with space followed by a '#' cannot
have any meaning other than being a comment, hence it doesn't harm to
accept them as comments.
Largely based on patch by: Junio C Hamano <gitster@pobox.com>
[jc: updated test with quickfix from Torsten Bögershausen]
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, dissociating from a reference can fail very easily due to
pack files that are still in use when they want to be removed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After using "git checkout --detach", the reflog is left with an entry
like
checkout: moving from ... to HEAD
This message is parsed to generate the 'HEAD detached at' message in
'git branch' and 'git status', which leads to the not-so-useful message
'HEAD detached at HEAD'.
Instead, when parsing such reflog entry, resolve HEAD to the
corresponding commit in the reflog, so that the message becomes 'HEAD
detached at $sha1'.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This currently fails: the output is 'HEAD detached at HEAD'.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Strict mode is about not guessing where .git is. If the user points to a
.git file, we know exactly where the target .git dir will be. This makes
it possible to serve .git files as repository on the server side.
This may be needed even in local clone case because transport.c code
uses upload-pack for fetching remote refs. But right now the
clone/transport code goes with non-strict.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It matters for linked checkouts where 'refs' directory won't be
available in $GIT_DIR. is_git_directory() knows about $GIT_COMMON_DIR
and can handle this case.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, libcurl will follow circular http redirects
forever. Let's put a cap on this so that somebody who can
trigger an automated fetch of an arbitrary repository (e.g.,
for CI) cannot convince git to loop infinitely.
The value chosen is 20, which is the same default that
Firefox uses.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
