summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-04-08merge-recursive: switch directory rename detection defaultLibravatar Elijah Newren5-87/+552
When all of x/a, x/b, and x/c have moved to z/a, z/b, and z/c on one branch, there is a question about whether x/d added on a different branch should remain at x/d or appear at z/d when the two branches are merged. There are different possible viewpoints here: A) The file was placed at x/d; it's unrelated to the other files in x/ so it doesn't matter that all the files from x/ moved to z/ on one branch; x/d should still remain at x/d. B) x/d is related to the other files in x/, and x/ was renamed to z/; therefore x/d should be moved to z/d. Since there was no ability to detect directory renames prior to git-2.18, users experienced (A) regardless of context. Choice (B) was implemented in git-2.18, with no option to go back to (A), and has been in use since. However, one user reported that the merge results did not match their expectations, making the change of default problematic, especially since there was no notice printed when directory rename detection moved files. Note that there is also a third possibility here: C) There are different answers depending on the context and content that cannot be determined by git, so this is a conflict. Use a higher stage in the index to record the conflict and notify the user of the potential issue instead of silently selecting a resolution for them. Add an option for users to specify their preference for whether to use directory rename detection, and default to (C). Even when directory rename detection is on, add notice messages about files moved into new directories. As a sidenote, x/d did not have to be a new file here; it could have already existed at some other path and been renamed to x/d, with directory rename detection just renaming it again to z/d. Thus, it's not just new files, but also a modification to all rename types (normal renames, rename/add, rename/delete, rename/rename(1to1), rename/rename(1to2), and rename/rename(2to1)). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: give callers of handle_content_merge() access to contentsLibravatar Elijah Newren1-17/+20
Pass a merge_file_info struct to handle_content_merge() so that the callers can access the oid and mode of the result afterward. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: track information associated with directory renamesLibravatar Elijah Newren1-14/+23
Directory rename detection previously silently applied. In order to allow printing information about paths that changed or printing a conflict notification (and only doing so near other potential conflict messages associated with the paths), save this information inside the rename struct for later use. A subsequent patch will make use of the additional information. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08t6043: fix copied test description to match its purposeLibravatar Elijah Newren1-2/+2
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: switch from (oid,mode) pairs to a diff_filespecLibravatar Elijah Newren1-268/+215
There was a significant inconsistency in the various parts of the API used in merge-recursive; many places used a pair of (oid, mode) to track file version/contents, while other parts used a diff_filespec (which have an oid and mode embedded in it). This inconsistency caused lots of places to need to pack and unpack data to call into other functions. This has been the subject of some past cleanups (see e.g. commit 0270a07ad0b2 ("merge-recursive: remove final remaining caller of merge_file_one()", 2018-09-19)), but let's just remove the underlying mess altogether by switching to use diff_filespec. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: cleanup handle_rename_* function signaturesLibravatar Elijah Newren1-16/+15
Instead of passing various bits and pieces of 'ci', just pass it directly. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: track branch where rename occurred in rename structLibravatar Elijah Newren1-71/+42
We previously tracked the branch associated with a rename in a separate field in rename_conflict_info, but since it is directly associated with the rename it makes more sense to move it into the rename struct. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: remove ren[12]_other fields from rename_conflict_infoLibravatar Elijah Newren1-50/+21
The ren1_other and ren2_other fields were synthesized from information in ren1->src_entry and ren2->src_entry. Since we already have the necessary information in ren1 and ren2, just use those. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: shrink rename_conflict_infoLibravatar Elijah Newren1-70/+50
The rename_conflict_info struct used both a pair and a stage_data which were taken from a rename struct. Just use the original rename struct. This will also allow us to start making other simplifications to the code. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: move some struct declarations togetherLibravatar Elijah Newren1-39/+39
These structs are related and reference each other, so move them together to make it easier for folks to determine what they hold and what their purpose is. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: use 'ci' for rename_conflict_info variable nameLibravatar Elijah Newren1-23/+18
We used a couple different names, but used 'ci' the most. Use the same variable name throughout for a little extra consistency. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: rename locals 'o' and 'a' to 'obuf' and 'abuf'Libravatar Elijah Newren1-8/+10
Since we want to replace oid,mode pairs with a single diff_filespec, we will soon want to be able to use the names 'o', 'a', and 'b' for the three different file versions. Rename some local variables in blob_unchanged() that would otherwise conflict. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: rename diff_filespec 'one' to 'o'Libravatar Elijah Newren1-23/+23
In the previous commit, we noted that several places throughout merge recursive both had a reason to use 'o'; some for a merge_options struct, and others for a diff_filespec struct. Some places had both, forcing one of the two to be renamed, though the choice was inconsistent. Now that the merge_options struct has been renamed to 'opt' everywhere, we can replace the few places that used 'one' for the diff_filespec to 'o'. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08merge-recursive: rename merge_options argument from 'o' to 'opt'Libravatar Elijah Newren1-492/+492
The name 'o' was used for the merge_options struct pointer taken by many functions, but in a few places it was named 'opt'. Several functions that didn't need merge_options instead used 'o' for a diff_filespec argument or local. Some functions needed both an inconsistently either renamed the merge_options to 'opt' or the diff_filespec to 'one'. I want to remove the weird split in the codebase between using a diff_filespec and a pair of (oid,mode) values in favor of using a diff_filespec everywhere, but that dramatically increases the number of cases where we want to use 'o' as a diff_filespec. Rename the merge_options argument to 'opt' to make room. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08Use 'unsigned short' for mode, like diff_filespec doesLibravatar Elijah Newren15-24/+24
struct diff_filespec defines mode to be an 'unsigned short'. Several other places in the API which we'd like to interact with using a diff_filespec used a plain unsigned (or unsigned int). This caused problems when taking addresses, so switch to unsigned short. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-20The third batchLibravatar Junio C Hamano1-0/+49
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-20Merge branch 'br/commit-tree-parseopt'Libravatar Junio C Hamano3-74/+104
The command line parser of "git commit-tree" has been rewritten to use the parse-options API. * br/commit-tree-parseopt: commit-tree: utilize parse-options api
2019-03-20Merge branch 'jk/config-type-color-ends-with-lf'Libravatar Junio C Hamano1-1/+3
"git config --type=color ..." is meant to replace "git config --get-color" but there is a slight difference that wasn't documented, which is now fixed. * jk/config-type-color-ends-with-lf: config: document --type=color output is a complete line
2019-03-20Merge branch 'ma/clear-repository-format'Libravatar Junio C Hamano5-18/+63
The setup code has been cleaned up to avoid leaks around the repository_format structure. * ma/clear-repository-format: setup: fix memory leaks with `struct repository_format` setup: free old value before setting `work_tree`
2019-03-20Merge branch 'jk/virtual-objects-do-exist'Libravatar Junio C Hamano2-1/+11
A recent update broke "is this object available to us?" check for well-known objects like an empty tree (which should yield "yes", even when there is no on-disk object for an empty tree), which has been corrected. * jk/virtual-objects-do-exist: rev-list: allow cached objects in existence check
2019-03-20Merge branch 'jk/no-sigpipe-during-network-transport'Libravatar Junio C Hamano3-5/+12
On platforms where "git fetch" is killed with SIGPIPE (e.g. OSX), the upload-pack that runs on the other end that hangs up after detecting an error could cause "git fetch" to die with a signal, which led to a flakey test. "git fetch" now ignores SIGPIPE during the network portion of its operation (this is not a problem as we check the return status from our write(2)s). * jk/no-sigpipe-during-network-transport: fetch: ignore SIGPIPE during network operation fetch: avoid calling write_or_die()
2019-03-20Merge branch 'jk/fsck-doc'Libravatar Junio C Hamano3-5/+90
"git fsck --connectivity-only" omits computation necessary to sift the objects that are not reachable from any of the refs into unreachable and dangling. This is now enabled when dangling objects are requested (which is done by default, but can be overridden with the "--no-dangling" option). * jk/fsck-doc: fsck: always compute USED flags for unreachable objects doc/fsck: clarify --connectivity-only behavior
2019-03-20Merge branch 'js/stress-test-ui-tweak'Libravatar Junio C Hamano2-4/+13
Dev support. * js/stress-test-ui-tweak: tests: introduce --stress-jobs=<N> tests: let --stress-limit=<N> imply --stress
2019-03-20Merge branch 'js/rebase-orig-head-fix'Libravatar Junio C Hamano2-16/+30
"git rebase" that was reimplemented in C did not set ORIG_HEAD correctly, which has been corrected. * js/rebase-orig-head-fix: built-in rebase: set ORIG_HEAD just once, before the rebase built-in rebase: demonstrate that ORIG_HEAD is not set correctly built-in rebase: use the correct reflog when switching branches built-in rebase: no need to check out `onto` twice
2019-03-20Merge branch 'jk/bisect-final-output'Libravatar Junio C Hamano2-17/+8
The final report from "git bisect" used to show the suspected culprit using a raw "diff-tree", with which there is no output for a merge commit. This has been updated to use a more modern and human readable output that still is concise enough. * jk/bisect-final-output: bisect: make diff-tree output prettier bisect: fix internal diff-tree config loading bisect: use string arguments to feed internal diff-tree
2019-03-20Merge branch 'ab/makefile-help-devs-more'Libravatar Junio C Hamano2-52/+55
CFLAGS now can be tweaked when invoking Make while using DEVELOPER=YesPlease; this did not work well before. * ab/makefile-help-devs-more: Makefile: allow for combining DEVELOPER=1 and CFLAGS="..." Makefile: move the setting of *FLAGS closer to "include" Makefile: Move *_LIBS assignment into its own section Makefile: add/remove comments at top and tweak whitespace Makefile: move "strip" assignment down from flags Makefile: remove an out-of-date comment
2019-03-18Merge git://ozlabs.org/~paulus/gitkLibravatar Junio C Hamano1-317/+343
* git://ozlabs.org/~paulus/gitk: gitk: Update Bulgarian translation (317t)
2019-03-14gitk: Update Bulgarian translation (317t)Libravatar Alexander Shopov1-317/+343
Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-03-11The second batchLibravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-11Sync with maintLibravatar Junio C Hamano1-1/+1
* maint: mingw: allow building with an MSYS2 runtime v3.x
2019-03-11Merge branch 'js/rebase-recreate-merge'Libravatar Junio C Hamano1-1/+1
Docfix. * js/rebase-recreate-merge: rebase docs: fix "gitlink" typo
2019-03-11Merge branch 'js/untravis-windows'Libravatar Junio C Hamano2-113/+0
Dev support. * js/untravis-windows: travis: remove the hack to build the Windows job on Azure Pipelines
2019-03-11Merge branch 'rd/gc-prune-doc-fix'Libravatar Junio C Hamano1-1/+1
Doxfix. * rd/gc-prune-doc-fix: docs/git-gc: fix typo "--prune=all" to "--prune=now"
2019-03-11Merge branch 'js/find-lib-h-with-ls-files-when-possible'Libravatar Junio C Hamano1-2/+3
The Makefile uses 'find' utility to enumerate all the *.h header files, which is expensive on platforms with slow filesystems; it now optionally uses "ls-files" if working within a repository, which is a trick similar to how all sources are enumerated to run ETAGS on. * js/find-lib-h-with-ls-files-when-possible: Makefile: use `git ls-files` to list header files, if possible
2019-03-11Merge branch 'rj/hdr-check-gcrypt-fix'Libravatar Junio C Hamano1-1/+4
The set of header files used by "make hdr-check" unconditionally included sha256/gcrypt.h, even when it is not used, causing the make target to fail. We now skip it when GCRYPT_SHA256 is not in use. * rj/hdr-check-gcrypt-fix: Makefile: fix 'hdr-check' when GCRYPT not installed
2019-03-11Merge branch 'jk/guard-bswap-header'Libravatar Junio C Hamano1-0/+5
The include file compat/bswap.h has been updated so that it is safe to (accidentally) include it more than once. * jk/guard-bswap-header: compat/bswap: add include header guards
2019-03-11Merge branch 'rd/attr.c-comment-typofix'Libravatar Junio C Hamano1-4/+4
In-code comment typofix. * rd/attr.c-comment-typofix: attr.c: ".gitattribute" -> ".gitattributes" (comments)
2019-03-11Merge branch 'yb/utf-16le-bom-spellfix'Libravatar Junio C Hamano1-1/+1
Doc update. * yb/utf-16le-bom-spellfix: gitattributes.txt: fix typo
2019-03-11mingw: allow building with an MSYS2 runtime v3.xLibravatar Johannes Schindelin1-1/+1
Recently the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x. This has the very notable consequence that `$(uname -r)` no longer reports a version starting with "2", but a version with "3". That breaks our build, as df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13) simply did not expect the version reported by `uname -r` to depend on the underlying Cygwin version: it expected the reported version to match the "2" in "MSYS2". So let's invert that test case to test for *anything else* than a version starting with "1" (for MSys). That should safeguard us for the future, even if Cygwin ends up releasing versionsl like 314.272.65536. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-08mingw: drop MakeMaker referenceLibravatar Johannes Schindelin1-1/+0
In 20d2a30f8ffe (Makefile: replace perl/Makefile.PL with simple make rules, 2017-12-10), Git stopped using MakeMaker. Therefore, that definition in the MINGW-specific section became useless. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-08commit-tree: utilize parse-options apiLibravatar Brandon Richardson3-74/+104
Rather than parse options manually, which is both difficult to read and error prone, parse options supplied to commit-tree using the parse-options api. It was discovered that the --no-gpg-sign option was documented but not implemented in commit 70ddbd7767 (commit-tree: add missing --gpg-sign flag, 2019-01-19), and the existing implementation would attempt to translate the option as a tree oid. It was also suggested earlier in commit 55ca3f99ae (commit-tree: add and document --no-gpg-sign, 2013-12-13) that commit-tree should be migrated to utilize the parse-options api, which could help prevent mistakes like this in the future. Hence this change. Also update the documentation to better describe that mixing `-m` and `-F` options will correctly compose commit log messages in the order in which the options are given. In the process, mark various strings for translation. Signed-off-by: Brandon Richardson <brandon1024.br@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07config: document --type=color output is a complete lineLibravatar Jeff King1-1/+3
Even though the newer "--type=color" option to "git config" is meant to be upward compatible with the traditional "--get-color" option, unlike the latter, its output is not an incomplete line that lack the LF at the end. That makes it consistent with output of other types like "git config --type=bool". Document it, as it sometimes surprises unsuspecting users. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07Start 2.22 cycleLibravatar Junio C Hamano3-2/+81
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07Merge branch 'jt/http-auth-proto-v2-fix'Libravatar Junio C Hamano4-207/+213
Unify RPC code for smart http in protocol v0/v1 and v2, which fixes a bug in the latter (lack of authentication retry) and generally improves the code base. * jt/http-auth-proto-v2-fix: remote-curl: use post_rpc() for protocol v2 also remote-curl: refactor reading into rpc_state's buf remote-curl: reduce scope of rpc_state.result remote-curl: reduce scope of rpc_state.stdin_preamble remote-curl: reduce scope of rpc_state.argv
2019-03-07Merge branch 'jk/diff-no-index-initialize'Libravatar Junio C Hamano4-17/+21
"git diff --no-index" may still want to access Git goodies like --ext-diff and --textconv, but so far these have been ignored, which has been corrected. * jk/diff-no-index-initialize: diff: reuse diff setup for --no-index case
2019-03-07Merge branch 'nd/no-more-check-racy'Libravatar Junio C Hamano1-28/+0
Unused code removal. * nd/no-more-check-racy: Delete check-racy.c
2019-03-07Merge branch 'rd/doc-hook-used-in-sample'Libravatar Junio C Hamano1-0/+4
Doc update. * rd/doc-hook-used-in-sample: mention use of "hooks.allownonascii" in "man githooks"
2019-03-07Merge branch 'nd/diff-parseopt-2'Libravatar Junio C Hamano2-211/+319
Second batch to teach the diff machinery to use the parse-options API. * nd/diff-parseopt-2: (21 commits) diff-parseopt: convert --ignore-some-changes diff-parseopt: convert --[no-]minimal diff-parseopt: convert --relative diff-parseopt: convert --no-renames|--[no--rename-empty diff-parseopt: convert --find-copies-harder diff-parseopt: convert -C|--find-copies diff-parseopt: convert -D|--irreversible-delete diff-parseopt: convert -M|--find-renames diff-parseopt: convert -B|--break-rewrites diff-parseopt: convert --output-* diff-parseopt: convert --[no-]compact-summary diff-parseopt: convert --stat* diff-parseopt: convert -s|--no-patch diff-parseopt: convert --name-status diff-parseopt: convert --name-only diff-parseopt: convert --patch-with-stat diff-parseopt: convert --summary diff-parseopt: convert --check diff-parseopt: convert --dirstat and friends diff-parseopt: convert --numstat and --shortstat ...
2019-03-07Merge branch 'en/merge-options-doc'Libravatar Junio C Hamano1-3/+8
Doc update. * en/merge-options-doc: merge-options.txt: correct wording of --no-commit option
2019-03-07Merge branch 'nd/completion-more-parameters'Libravatar Junio C Hamano18-4/+126
The command line completion (in contrib/) has been taught to complete more subcommand parameters. * nd/completion-more-parameters: completion: add more parameter value completion