Oftentimes, patches created by git format-patch will be stored in
version control or compared with diff. In these cases, two otherwise
identical patches can have different commit hashes, leading to diff
noise. Teach git format-patch a --zero-commit option that instead
produces an all-zero hash to avoid this diff noise.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extend transfer.hideRefs to work better with use of namespaces.
* lf/ref-is-hidden-namespace:
t5509: add basic tests for hideRefs
hideRefs: add support for matching full refs
upload-pack: strip refs before calling ref_is_hidden()
config.txt: document the semantics of hideRefs with namespaces
Having a leftover .idx file without corresponding .pack file in
the repository hurts performance; "git gc" learned to prune them.
* dk/gc-idx-wo-pack:
gc: remove garbage .idx files from pack dir
t5304: test cleaning pack garbage
prepare_packed_git(): refactor garbage reporting in pack directory
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Lukas Fleischer <lfleischer@lfos.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a custom report_garbage handler to collect and remove
garbage .idx files from the pack directory.
Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pack garbage, noticeably stale .idx files, can be cleaned up during
a garbage collection. This tests to ensure such garbage is properly
cleaned up.
Note that the prior test for checking pack garbage with count-objects
left some stale garbage after the test exited. This has also been
corrected.
Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git blame" learnt to take "--first-parent" and "--reverse" at the
same time when it makes sense.
* mk/blame-first-parent:
blame: allow blame --reverse --first-parent when it makes sense
blame: extract find_single_final
blame: test to describe use of blame --reverse --first-parent
"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
The code to prepare the working tree side of temporary directory
for the "dir-diff" feature forgot that symbolic links need not be
copied (or symlinked) to the temporary area, as the code already
special cases and overwrites them. Besides, it was wrong to try
computing the object name of the target of symbolic link, which may
not even exist or may be a directory.
* da/difftool:
difftool: ignore symbolic links in use_wt_file
Using the timestamp based criteria in "git branch --sort" did not
tiebreak branches that point at commits with the same timestamp (or
the same commit), making the resulting output unstable.
* kn/for-each-branch:
ref-filter: fallback on alphabetical comparison
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>
Allow combining --reverse and --first-parent if initial commit of
specified range is at the first-parent chain starting from the final
commit. Disable the prepare_revision_walk()'s builtin children
collection, instead picking only the ones which are along the first
parent chain.
Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reverse blame can be used to locate removal of lines which does not
change adjacent lines. Such edits do not appear in non-reverse blame,
because the adjacent lines last changed commit is older history, before
the edit.
For a big and active project which uses topic branches, or analogous
feature, for example pull-requests, the history can contain many
concurrent branches, and even after an edit merged into the target
branch, there are still many (sometimes several tens or even hundreds)
topic branch which do not contain it:
a0--a1-----*a2-*a3-a4...-*a100
|\ / / /
| b0-B1..bN / /
|\ / /
| c0.. ..cN /
\ /
z0.. ..zN
Here, the '*'s mark the first parent in merge, and uppercase B1 - the
commit where the line being blamed for was removed. Since commits cN-zN
do not contain B1, they still have the line removed in B1, and
reverse blame can report that the last commit for the line was zN
(meaning that it was removed in a100). In fact it really does return
some very late commit, and this makes it unusable for finding the B1
commit.
The search could be done by blame --reverse --first-parent. For range
a0..a100 it would return a1, and then only one additional blame along
the a0..bN will return the desired commit b0. But combining --reverse
and --first-parent was forbidden in 95a4fb0eac, because incorrectly
specified range could produce unexpected and meaningless result.
Add test which describes the expected behavior of
`blame --reverse --first-parent` in the case described above.
Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When prefixing a Git call in the test suite with 'debug ', it will
now be run with GDB, allowing the developer to debug test failures
more conveniently.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In ref-filter.c the comparison of refs while sorting is handled by
cmp_ref_sorting() function. When sorting as per numerical values
(e.g. --sort=objectsize) there is no fallback comparison when both
refs hold the same value. This can cause unexpected results (i.e. the
order of listing refs with equal values cannot be pre-determined) as
pointed out by Johannes Sixt ($gmane/280117).
Hence, fallback to alphabetical comparison based on the refname
whenever the other criterion is equal.
A test in t3203 was expecting that branch-two sorts before HEAD, which
happened to be how qsort(3) on Linux sorted the array, but (1) that
outcome was not even guaranteed, and (2) once we start breaking ties
with the refname, "HEAD" should sort before "branch-two" so the
original expectation was inconsistent with the criterion we now use.
Update it to match the new world order, which we can now depend on
being stable.
Helped-by: Junio C Hamano <gitster@pobox.com>
Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"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
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
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
"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
"git clone --dissociate" used to require that "--reference" was
used at the same time, but you can create a new repository that
borrows objects from another without using "--reference", namely
with "clone --local" from a repository that borrows objects from
other repositories.
* ar/clone-dissociate:
clone: allow "--dissociate" without reference
The caller is preparing a narrowed-down copy of the working tree and
this function is asked if the path should be included in that copy.
If we say yes, the path from the working tree will be either symlinked
or copied into the narrowed-down copy.
For any path that is a symbolic link, the caller later fixes up the
narrowed-down copy by unlinking the path and replacing it with a
regular file it writes out that mimics the way how "git diff"
compares symbolic links.
Let's answer "no, you do not want to copy/symlink the working tree
file" for all symbolic links from this function, as we know the
result will not be used because it will be overwritten anyway.
Incidentally, this also stops the function from feeding a symbolic
link in the working tree to hash-object, which is a wrong thing to
do to begin with. The link may be pointing at a directory, or worse
may be dangling (both would be noticed as an error). Even if the
link points at a regular file, hashing the contents of a file that
is pointed at by the link is not correct (Git hashes the contents of
the link itself, not the pointee).
Signed-off-by: David Aguilar <davvid@gmail.com>
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>
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
Add the "list" subcommand to "git worktree".
* mr/worktree-list:
worktree: add 'list' command
worktree: add details to the worktree struct
worktree: add a function to get worktree details
worktree: refactor find_linked_symref function
worktree: add top-level worktree.c
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>
The "--reference" option is not the only way to provide a repository
to borrow objects from. A repository that borrows from another
repository can be cloned with "clone --local" and the resulting
repository will borrow from the same repository, which the user
may want to "--dissociate" from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A few test scripts around "git p4" have been improved for
portability.
* ls/p4-test-updates:
git-p4: skip t9819 test case on case insensitive file systems
git-p4: avoid "stat" command in t9815 git-p4-submit-fail
Many allocations that is manually counted (correctly) that are
followed by strcpy/sprintf have been replaced with a less error
prone constructs such as xstrfmt.
Macintosh-specific breakage was noticed and corrected in this
reroll.
* jk/war-on-sprintf: (70 commits)
name-rev: use strip_suffix to avoid magic numbers
use strbuf_complete to conditionally append slash
fsck: use for_each_loose_file_in_objdir
Makefile: drop D_INO_IN_DIRENT build knob
fsck: drop inode-sorting code
convert strncpy to memcpy
notes: document length of fanout path with a constant
color: add color_set helper for copying raw colors
prefer memcpy to strcpy
help: clean up kfmclient munging
receive-pack: simplify keep_arg computation
avoid sprintf and strcpy with flex arrays
use alloc_ref rather than hand-allocating "struct ref"
color: add overflow checks for parsing colors
drop strcpy in favor of raw sha1_to_hex
use sha1_to_hex_r() instead of strcpy
daemon: use cld->env_array when re-spawning
stat_tracking_info: convert to argv_array
http-push: use an argv_array for setup_revisions
fetch-pack: use argv_array for index-pack / unpack-objects
...
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>
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
Teach "git p4" to send large blobs outside the repository by
talking to Git LFS.
* ls/p4-lfs:
git-p4: add Git LFS backend for large file system
git-p4: add support for large file systems
git-p4: check free space during streaming
git-p4: add file streaming progress in verbose mode
git-p4: return an empty list if a list config has no values
git-p4: add gitConfigInt reader
git-p4: add optional type specifier to gitConfig reader
"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
"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`
"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
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
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
Update "git branch" that list existing branches, using the
ref-filter API that is shared with "git tag" and "git
for-each-ref".
* kn/for-each-branch:
branch: add '--points-at' option
branch.c: use 'ref-filter' APIs
branch.c: use 'ref-filter' data structures
branch: drop non-commit error reporting
branch: move 'current' check down to the presentation layer
branch: roll show_detached HEAD into regular ref_list
branch: bump get_head_description() to the top
branch: refactor width computation
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
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
