summaryrefslogtreecommitdiff
path: root/merge-recursive.h
AgeCommit message (Collapse)AuthorFilesLines
2018-05-08merge: add merge.renames config settingLibravatar Ben Peart1-1/+8
Add the ability to control rename detection for merge via a config setting. This setting behaves the same and defaults to the value of diff.renames but only applies to merge. Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Ben Peart <benpeart@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-08merge-recursive: fix was_tracked() to quit lying with some renamed pathsLibravatar Elijah Newren1-0/+1
In commit aacb82de3ff8 ("merge-recursive: Split was_tracked() out of would_lose_untracked()", 2011-08-11), was_tracked() was split out of would_lose_untracked() with the intent to provide a function that could answer whether a path was tracked in the index before the merge. Sadly, it instead returned whether the path was in the working tree due to having been tracked in the index before the merge OR having been written there by unpack_trees(). The distinction is important when renames are involved, e.g. for a merge where: HEAD: modifies path b other: renames b->c In this case, c was not tracked in the index before the merge, but would have been added to the index at stage 0 and written to the working tree by unpack_trees(). would_lose_untracked() is more interested in the in-working-copy-for-either-reason behavior, while all other uses of was_tracked() want just was-it-tracked-in-index-before-merge behavior. Unsplit would_lose_untracked() and write a new was_tracked() function which answers whether a path was tracked in the index before the merge started. This will also affect was_dirty(), helping it to return better results since it can base answers off the original index rather than an index that possibly only copied over some of the stat information. However, was_dirty() will need an additional change that will be made in a subsequent patch. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-08merge-recursive: fix overwriting dirty files involved in renamesLibravatar Elijah Newren1-0/+2
This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-08merge-recursive: add computation of collisions due to dir rename & mergingLibravatar Elijah Newren1-0/+7
directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-08merge-recursive: add get_directory_renames()Libravatar Elijah Newren1-0/+18
This populates a set of directory renames for us. The set of directory renames is not yet used, but will be in subsequent commits. Note that the use of a string_list for possible_new_dirs in the new dir_rename_entry struct implies an O(n^2) algorithm; however, in practice I expect the number of distinct directories that files were renamed into from a single original directory to be O(1). My guess is that n has a mode of 1 and a mean of less than 2, so, for now, string_list seems good enough for possible_new_dirs. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11Revert "Merge branch 'en/rename-directory-detection'"Libravatar Junio C Hamano1-27/+0
This reverts commit e4bb62fa1eeee689744b413e29a50b4d1dae6886, reversing changes made to 468165c1d8a442994a825f3684528361727cd8c0. The topic appears to inflict severe regression in renaming merges, even though the promise of it was that it would improve them. We do not yet know which exact change in the topic was wrong, but in the meantime, let's play it safe and revert it out of 'master' before real Git-using projects are harmed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-27merge-recursive: fix overwriting dirty files involved in renamesLibravatar Elijah Newren1-0/+2
This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-14merge-recursive: add computation of collisions due to dir rename & mergingLibravatar Elijah Newren1-0/+7
directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-14merge-recursive: add get_directory_renames()Libravatar Elijah Newren1-0/+18
This populates a set of directory renames for us. The set of directory renames is not yet used, but will be in subsequent commits. Note that the use of a string_list for possible_new_dirs in the new dir_rename_entry struct implies an O(n^2) algorithm; however, in practice I expect the number of distinct directories that files were renamed into from a single original directory to be O(1). My guess is that n has a mode of 1 and a mean of less than 2, so, for now, string_list seems good enough for possible_new_dirs. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-08merge-recursive: change current file dir string_lists to hashmapLibravatar Kevin Willford1-2/+1
The code was using two string_lists, one for the directories and one for the files. The code never checks the lists independently so we should be able to only use one list. The string_list also is a O(log n) for lookup and insertion. Switching this to use a hashmap will give O(1) which will save some time when there are millions of paths that will be checked. Signed-off-by: Kevin Willford <kewillf@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01merge-recursive: offer an option to retain the output in 'obuf'Libravatar Johannes Schindelin1-1/+1
Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we already accumulate the output in a buffer. The idea was to avoid interfering with the progress output that goes to stderr, which is unbuffered, when we write to stdout, which is buffered. We extend that buffering to allow the caller to handle the output (possibly suppressing it). This will help us when extending the sequencer to do rebase -i's brunt work: it does not want the picks to print anything by default but instead determine itself whether to print the output or not. Note that we also redirect the error messages into the output buffer when the caller asked not to flush the output buffer, for two reasons: 1) to retain the correct output order, and 2) to allow the caller to suppress *all* output. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28merge-recursive: convert merge_recursive_generic() to object_idLibravatar brian m. carlson1-3/+3
Convert this function and the git merge-recursive subcommand to use struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17merge-recursive: option to disable renamesLibravatar Felipe Gonçalves Assis1-0/+1
The recursive strategy turns on rename detection by default. Add a strategy option to disable rename detection even for exact renames. Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-29Move try_merge_command and checkout_fast_forward to libgit.aLibravatar Nguyễn Thái Ngọc Duy1-5/+0
These functions are called in sequencer.c, which is part of libgit.a. This makes libgit.a potentially require builtin/merge.c for external git commands. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2011-08-14merge-recursive: Save D/F conflict filenames instead of unlinking themLibravatar Elijah Newren1-0/+1
Rename make_room_for_directories_of_df_conflicts() to record_df_conflict_files() to reflect the change in functionality. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19Merge branch 'jk/merge-rename-ux'Libravatar Junio C Hamano1-0/+2
* jk/merge-rename-ux: pull: propagate --progress to merge merge: enable progress reporting for rename detection add inexact rename detection progress infrastructure commit: stop setting rename limit bump rename limit defaults (again) merge: improve inexact rename limit warning
2011-02-21merge: enable progress reporting for rename detectionLibravatar Jeff King1-0/+1
The user can enable or disable it explicitly with the new --progress, but it defaults to checking isatty(2). This works only with merge-recursive and subtree. In theory we could pass a progress flag to other strategies, but none of them support progress at this point, so let's wait until they grow such a feature before worrying about propagating it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21merge: improve inexact rename limit warningLibravatar Jeff King1-0/+1
The warning is generated deep in the diffcore code, which means that it will come first, followed possibly by a spew of conflicts, making it hard to see. Instead, let's have diffcore pass back the information about how big the rename limit would needed to have been, and then the caller can provide a more appropriate message (and at a more appropriate time). No refactoring of other non-merge callers is necessary, because nobody else was even using the warn_on_rename_limit feature. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-28cherry-pick/revert: add support for -X/--strategy-optionLibravatar Jonathan Nieder1-1/+3
For example, this would allow cherry-picking or reverting patches from a piece of history with a different end-of-line style, like so: $ git revert -Xrenormalize old-problematic-commit Currently that is possible with manual use of merge-recursive but the cherry-pick/revert porcelain does not expose the functionality. While at it, document the existing support for --strategy. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-26Merge branch 'kb/merge-recursive-rename-threshold'Libravatar Junio C Hamano1-0/+1
* kb/merge-recursive-rename-threshold: diff: add synonyms for -M, -C, -B merge-recursive: option to specify rename threshold Conflicts: Documentation/diff-options.txt Documentation/merge-strategies.txt
2010-10-26Merge branch 'jf/merge-ignore-ws'Libravatar Junio C Hamano1-0/+3
* jf/merge-ignore-ws: merge-recursive: options to ignore whitespace changes merge-recursive --patience ll-merge: replace flag argument with options struct merge-recursive: expose merge options for builtin merge
2010-09-29merge-recursive: option to specify rename thresholdLibravatar Kevin Ballard1-0/+1
The recursive merge strategy turns on rename detection but leaves the rename threshold at the default. Add a strategy option to allow the user to specify a rename threshold to use. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'dg/local-mod-error-messages'Libravatar Junio C Hamano1-6/+0
* dg/local-mod-error-messages: t7609-merge-co-error-msgs: test non-fast forward case too. Move "show_all_errors = 1" to setup_unpack_trees_porcelain() setup_unpack_trees_porcelain: take the whole options struct as parameter Move set_porcelain_error_msgs to unpack-trees.c and rename it Conflicts: merge-recursive.c
2010-09-03Merge branch 'jn/merge-renormalize'Libravatar Junio C Hamano1-0/+1
* jn/merge-renormalize: merge-recursive --renormalize rerere: never renormalize rerere: migrate to parse-options API t4200 (rerere): modernize style ll-merge: let caller decide whether to renormalize ll-merge: make flag easier to populate Documentation/technical: document ll_merge merge-trees: let caller decide whether to renormalize merge-trees: push choice to renormalize away from low level t6038 (merge.renormalize): check that it can be turned off t6038 (merge.renormalize): try checkout -m and cherry-pick t6038 (merge.renormalize): style nitpicks Don't expand CRLFs when normalizing text during merge Try normalizing files to avoid delete/modify conflicts when merging Avoid conflicts when merging branches with mixed normalization Conflicts: builtin/rerere.c t/t4200-rerere.sh
2010-09-03Move set_porcelain_error_msgs to unpack-trees.c and rename itLibravatar Matthieu Moy1-6/+0
The function is currently dealing only with error messages, but the intent of calling it is really to notify the unpack-tree mechanics that it is running in porcelain mode. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-26merge-recursive --patienceLibravatar Justin Frankel1-0/+1
Teach the merge-recursive strategy a --patience option to use the "patience diff" algorithm, which tends to improve results when cherry-picking a patch that reorders functions at the same time as refactoring them. To support this, struct merge_options and ll_merge_options gain an xdl_opts member, so programs can use arbitrary xdiff flags (think "XDF_IGNORE_WHITESPACE") in a git-aware merge. git merge and git rebase can be passed the -Xpatience option to use this. [jn: split from --ignore-space patch; with documentation] Signed-off-by: Justin Frankel <justin@cockos.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-26merge-recursive: expose merge options for builtin mergeLibravatar Jonathan Nieder1-0/+2
There are two very similar blocks of code that recognize options for the "recursive" merge strategy. Unify them. No functional change intended. Cc: Avery Pennarun <apenwarr@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11merge-recursive: porcelain messages for checkoutLibravatar Diane Gasselin1-2/+5
A porcelain message was first added in checkout.c in the commit 8ccba008 (Junio C Hamano, Sat May 17 21:03:49 2008, unpack-trees: allow Porcelain to give different error messages) to give better feedback in the case of merge errors. This patch adapts the porcelain messages for the case of checkout instead. This way, when having a checkout error, "merge" no longer appears in the error message. While we're there, we add an advice in the case of would_lose_untracked_file. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11Turn unpack_trees_options.msgs into an array + enumLibravatar Matthieu Moy1-2/+2
The list of error messages was introduced as a structure, but an array indexed over an enum is more flexible, since it allows one to store a type of error message (index in the array) in a variable. This change needs to rename would_lose_untracked -> would_lose_untracked_file to avoid a clash with the function would_lose_untracked in merge-recursive.c. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06merge-trees: let caller decide whether to renormalizeLibravatar Jonathan Nieder1-0/+1
Add a "renormalize" option to struct merge_options so callers can decide on a case-by-case basis whether the merge is likely to have overlapped with a change in smudge/clean rules. The option defaults to the global merge_renormalize setting for now. No change in behavior intended. Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-21Merge branch 'gv/portable'Libravatar Junio C Hamano1-1/+1
* gv/portable: test-lib: use DIFF definition from GIT-BUILD-OPTIONS build: propagate $DIFF to scripts Makefile: Tru64 portability fix Makefile: HP-UX 10.20 portability fixes Makefile: HPUX11 portability fixes Makefile: SunOS 5.6 portability fix inline declaration does not work on AIX Allow disabling "inline" Some platforms lack socklen_t type Make NO_{INET_NTOP,INET_PTON} configured independently Makefile: some platforms do not have hstrerror anywhere git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition test_cmp: do not use "diff -u" on platforms that lack one fixup: do not unconditionally disable "diff -u" tests: use "test_cmp", not "diff", when verifying the result Do not use "diff" found on PATH while building and installing enums: omit trailing comma for portability Makefile: -lpthread may still be necessary when libc has only pthread stubs Rewrite dynamic structure initializations to runtime assignment Makefile: pass CPPFLAGS through to fllow customization Conflicts: Makefile wt-status.h
2010-05-31enums: omit trailing comma for portabilityLibravatar Gary V. Vaughan1-1/+1
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git. enum style is inconsistent already, with some enums declared on one line, some over 3 lines with the enum values all on the middle line, sometimes with 1 enum value per line... and independently of that the trailing comma is sometimes present and other times absent, often mixing with/without trailing comma styles in a single file, and sometimes in consecutive enum declarations. Clearly, omitting the comma is the more portable style, and this patch changes all enum declarations to use the portable omitted dangling comma style consistently. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-01merge: make function try_merge_command non staticLibravatar Christian Couder1-0/+3
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20merge_trees(): add ancestor label parameter for diff3-style outputLibravatar Jonathan Nieder1-0/+1
Commands using the merge_trees() machinery will present conflict hunks in output something like what ‘diff3 -m’ produces if the merge.conflictstyle configuration option is set to diff3. The output lacks the name of the merge base on the ||||||| line of the output, and tools can misparse the conflict hunks without it. Add a new o->ancestor parameter to merge_trees() for use as a label for the ancestor in conflict hunks. If o->ancestor is NULL, the output format is as before. All callers pass NULL for now. If o->ancestor is non-NULL and both branches renamed the base file to the same name, that name is included in the conflict hunk labels. Even if o->ancestor is NULL I think this would be a good change, but this patch only does it in the non-NULL case to ensure the output format does not change where it might matter. Requested-by: Stefan Monnier <monnier@iro.umontreal.ca> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'ap/merge-backend-opts'Libravatar Junio C Hamano1-1/+6
* ap/merge-backend-opts: Document that merge strategies can now take their own options Extend merge-subtree tests to test -Xsubtree=dir. Make "subtree" part more orthogonal to the rest of merge-recursive. pull: Fix parsing of -X<option> Teach git-pull to pass -X<option> to git-merge git merge -X<option> git-merge-file --ours, --theirs Conflicts: git-compat-util.h
2010-01-17Make "subtree" part more orthogonal to the rest of merge-recursive.Libravatar Junio C Hamano1-1/+2
This makes "subtree" more orthogonal to the rest of recursive merge, so that you can use subtree and ours/theirs features at the same time. For example, you can now say: git merge -s subtree -Xtheirs other to merge with "other" branch while shifting it up or down to match the shape of the tree of the current branch, and resolving conflicts favoring the changes "other" branch made over changes made in the current branch. It also allows the prefix used to shift the trees to be specified using the "-Xsubtree=$prefix" option. Giving an empty prefix tells the command to figure out how much to shift trees automatically as we have always done. "merge -s subtree" is the same as "merge -s recursive -Xsubtree=" (or "merge -s recursive -Xsubtree"). Based on an old patch done back in the days when git-merge was a script; Avery ported the script part to builtin-merge.c. Bugs in shift_tree() is mine. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-17git merge -X<option>Libravatar Avery Pennarun1-1/+5
Teach "-X <option>" command line argument to "git merge" that is passed to strategy implementations. "ours" and "theirs" autoresolution introduced by the previous commit can be asked to the recursive strategy. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-29merge-recursive: make the error-message generation an extern functionLibravatar Matthieu Moy1-0/+3
The construction of the struct unpack_trees_error_msgs was done within git_merge_trees(), which prevented using the same messages easily from another function. [jc: backported for 1.6.5 maint before advice_commit_before_merge] Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-04merge-recursive: move current_{file,directory}_set to struct merge_optionsLibravatar Miklos Vajna1-0/+4
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
2008-09-04merge-recursive: move the global obuf to struct merge_optionsLibravatar Miklos Vajna1-0/+1
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
2008-09-03merge-recursive: move call_depth to struct merge_optionsLibravatar Miklos Vajna1-0/+1
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
2008-08-30merge-recursive: introduce merge_optionsLibravatar Miklos Vajna1-13/+29
This makes it possible to avoid passing the labels of branches as arguments to merge_recursive(), merge_trees() and merge_recursive_generic(). It also takes care of subtree merge, output buffering, verbosity, and rename limits - these were global variables till now in merge-recursive.c. A new function, named init_merge_options(), is introduced as well, it clears the struct merge_info, then initializes with default values, finally updates the default values based on the config and environment variables. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30merge-recursive.c: Add more generic merge_recursive_generic()Libravatar Stephan Beyer1-1/+3
merge_recursive_generic() takes, in comparison to to merge_recursive(), no commit ("struct commit *") arguments but SHA ids ("unsigned char *"), and no commit list of bases but an array of refs ("const char **"). This makes it more generic in the case that it can also take the SHA of a tree to merge trees without commits, for the bases, the head and the remote. merge_recursive_generic() also handles locking and updating of the index, which is a common use case of merge_recursive(). This patch also rewrites builtin-merge-recursive.c to make use of merge_recursive_generic(). By doing this, I stumbled over the limitation of 20 bases and I've added a warning if this limitation is exceeded. This patch qualifies make_virtual_commit() as static again because this function is not needed anymore outside merge-recursive.c. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30Split out merge_recursive() to merge-recursive.cLibravatar Miklos Vajna1-1/+5
Move most of the of code from builtin-merge-recursive.c to a new file merge-recursive.c and introduce merge_recursive_setup() in there so that builtin-merge-recursive and other builtins call it. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09Build-in merge-recursiveLibravatar Daniel Barkalow1-0/+20
This makes write_tree_from_memory(), which writes the active cache as a tree and returns the struct tree for it, available to other code. It also makes available merge_trees(), which does the internal merge of two trees with a known base, and merge_recursive(), which does the recursive internal merge of two commits with a list of common ancestors. The first two of these will be used by checkout -m, and the third is presumably useful in general, although the implementation of checkout -m which entirely matches the behavior of the shell version does not use it (since it ignores the difference of ancestry between the old branch and the new branch). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>