summaryrefslogtreecommitdiff
path: root/merge-recursive.c
AgeCommit message (Collapse)AuthorFilesLines
2010-09-15Merge branch 'ks/recursive-rename-add-identical'Libravatar Junio C Hamano1-0/+6
* ks/recursive-rename-add-identical: RE: [PATCH] Avoid rename/add conflict when contents are identical
2010-09-03Merge branch 'dg/local-mod-error-messages'Libravatar Junio C Hamano1-45/+1
* 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-03RE: [PATCH] Avoid rename/add conflict when contents are identicalLibravatar Schalk, Ken1-0/+6
>Due to this this (and maybe all the tests) need to depend on the >SYMLINKS prereq. Here's a third attempt with no use of symlinks in the test: Skip the entire rename/add conflict case if the file added on the other branch has the same contents as the file being renamed. This avoids giving the user an extra copy of the same file and presenting a conflict that is confusing and pointless. A simple test of this case has been added in t/t3030-merge-recursive.sh. Signed-off-by: Ken Schalk <ken.schalk@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Merge branch 'jn/merge-renormalize'Libravatar Junio C Hamano1-3/+54
* 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-03setup_unpack_trees_porcelain: take the whole options struct as parameterLibravatar Matthieu Moy1-1/+1
This is a preparation patch to let setup_unpack_trees_porcelain set show_all_errors itself. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03Move set_porcelain_error_msgs to unpack-trees.c and rename itLibravatar Matthieu Moy1-45/+1
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-31Merge branch 'en/d-f-conflict-fix'Libravatar Junio C Hamano1-19/+88
* en/d-f-conflict-fix: merge-recursive: Avoid excessive output for and reprocessing of renames merge-recursive: Fix multiple file rename across D/F conflict t6031: Add a testcase covering multiple renames across a D/F conflict merge-recursive: Fix typo Mark tests that use symlinks as needing SYMLINKS prerequisite t/t6035-merge-dir-to-symlink.sh: Remove TODO on passing test fast-import: Improve robustness when D->F changes provided in wrong order fast-export: Fix output order of D/F changes merge_recursive: Fix renames across paths below D/F conflicts merge-recursive: Fix D/F conflicts Add a rename + D/F conflict testcase Add additional testcases for D/F conflicts Conflicts: merge-recursive.c
2010-08-21Merge branch 'hv/submodule-find-ff-merge'Libravatar Junio C Hamano1-3/+6
* hv/submodule-find-ff-merge: Implement automatic fast-forward merge for submodules setup_revisions(): Allow walking history in a submodule Teach ref iteration module about submodules Conflicts: submodule.c
2010-08-21Merge branch 'dg/local-mod-error-messages'Libravatar Junio C Hamano1-20/+42
* dg/local-mod-error-messages: t7609: test merge and checkout error messages unpack_trees: group error messages by type merge-recursive: distinguish "removed" and "overwritten" messages merge-recursive: porcelain messages for checkout Turn unpack_trees_options.msgs into an array + enum Conflicts: t/t3400-rebase.sh
2010-08-20merge-recursive: Avoid excessive output for and reprocessing of renamesLibravatar Elijah Newren1-6/+2
In 5a2580d (merge_recursive: Fix renames across paths below D/F conflicts 2010-07-09) and ae74548 (merge-recursive: Fix multiple file rename across D/F conflict 2010-08-17), renames across D/F conflicts were fixed by making process_renames() consider as unprocessed renames whose dst_entry "still" had higher stage entries. The assumption was that those higher stage entries would have been cleared out of dst_entry by that point in cases where the conflict could be resolved (normal renames with no D/F conflicts). That is not the case -- higher stage entries will remain in all cases. Fix this by checking for higher stage entries corresponding to D/F conflicts, namely that stages 2 and 3 have exactly one nonzero mode between them. The nonzero mode stage corresponds to a file at the path, while the stage with a zero mode will correspond to a directory at that path (since rename/delete conflicts will have already been handled before this codepath is reached.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18Merge branch 'tf/string-list-init'Libravatar Junio C Hamano1-1/+2
* tf/string-list-init: string_list: Add STRING_LIST_INIT macro and make use of it.
2010-08-18Merge branch 'cc/find-commit-subject'Libravatar Junio C Hamano1-10/+4
* cc/find-commit-subject: blame: use find_commit_subject() instead of custom code merge-recursive: use find_commit_subject() instead of custom code bisect: use find_commit_subject() instead of custom code revert: rename variables related to subject in get_message() revert: refactor code to find commit subject in find_commit_subject() revert: fix off by one read when searching the end of a commit subject
2010-08-18merge-recursive: Fix multiple file rename across D/F conflictLibravatar Elijah Newren1-0/+1
In 5a2580d (merge_recursive: Fix renames across paths below D/F conflicts 2010-07-09), detection was added for renames across paths involved in a directory<->file conflict. However, the change accidentally involved reusing an outer loop index ('i') in an inner loop, changing its values and causing a slightly different type of breakage for cases where there are multiple renames across the D/F conflict. Fix by creating a new temporary variable 'i'. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18merge-recursive: Fix typoLibravatar Elijah Newren1-1/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11unpack_trees: group error messages by typeLibravatar Matthieu Moy1-6/+19
When an error is encountered, it calls add_rejected_file() which either - directly displays the error message and stops if in plumbing mode (i.e. if show_all_errors is not initialized at 1) - or stores it so that it will be displayed at the end with display_error_msgs(), Storing the files by error type permits to have a list of files for which there is the same error instead of having a serie of almost identical errors. As each bind_overlap error combines a file and an old file, a list cannot be done, therefore, theses errors are not stored but directly displayed. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11merge-recursive: distinguish "removed" and "overwritten" messagesLibravatar Matthieu Moy1-5/+8
To limit the number of possible error messages, the error messages for the case would_lose_untracked_file and would_lose_orphaned in unpack_trees_options.msgs were handled with a single string, parameterized by an action string ("overwritten" or "removed"). Instead, we consider them as two different cases, with unparameterized string. This will make it easier to make separate lists sorted by error types later. Only the bind_overlap case still takes two %s parameters, but that's unavoidable. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11merge-recursive: porcelain messages for checkoutLibravatar Diane Gasselin1-9/+22
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-18/+11
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-recursive --renormalizeLibravatar Jonathan Nieder1-1/+1
Teach "git merge-recursive" a --renormalize option to enable the merge.renormalize configuration. The --no-renormalize option can be used to override it in the negative. So in the future, you might be able to, e.g.: git checkout -m -Xrenormalize otherbranch or git revert -Xrenormalize otherpatch or git pull --rebase -Xrenormalize The bad part: merge.renormalize is still not honored for most commands. And it reveals lots of places that -X has not been plumbed in (so we get "git merge -Xrenormalize" but not much else). NEEDSWORK: tests 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-08-06ll-merge: let caller decide whether to renormalizeLibravatar Jonathan Nieder1-0/+1
Add a “renormalize” bit to the ll-merge options word 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. This reveals a few commands that have not been taking that situation into account, though it does not fix them. No functional change intended. Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Improved-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-06ll-merge: make flag easier to populateLibravatar Jonathan Nieder1-1/+2
ll_merge() takes its options in a flag word, which has a few advantages: - options flags can be cheaply passed around in registers, while an option struct passed by pointer cannot; - callers can easily pass 0 without trouble for no options, while an option struct passed by value would not allow that. The downside is that code to populate and access the flag word can be somewhat opaque. Mitigate that with a few macros. Cc: Avery Pennarun <apenwarr@gmail.com> Cc: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06merge-trees: let caller decide whether to renormalizeLibravatar Jonathan Nieder1-1/+2
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-08-06merge-trees: push choice to renormalize away from low levelLibravatar Jonathan Nieder1-4/+5
The merge machinery decides whether to resmudge and clean relevant entries based on the global merge_renormalize setting, which is set by "git merge" based on its configuration (and left alone by other commands). A nicer interface would make that decision a parameter to merge_trees so callers would pass in a choice made on a call-by-call basis. Start by making blob_unchanged stop examining the merge_renormalize global. In other words, this change is a trivial no-op, but it brings us closer to something good. 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-07-23merge-recursive: use find_commit_subject() instead of custom codeLibravatar Christian Couder1-10/+4
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-09merge-recursive: use "up-to-date" instead of "uptodate" in error message for ↵Libravatar Nicolas Sebrecht1-1/+1
consistency Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-09merge_recursive: Fix renames across paths below D/F conflictsLibravatar Elijah Newren1-2/+13
The rename logic in process_renames() handles renames and merging of file contents and then marks files as processed. However, there may be higher stage entries left in the index for other reasons (e.g., due to D/F conflicts). By checking for such cases and marking the entry as not processed, it allows process_entry() later to look at it and handle those higher stages. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-09merge-recursive: Fix D/F conflictsLibravatar Elijah Newren1-16/+77
The D/F conflicts that can be automatically resolved (file or directory unmodified on one side of history), have the nice property that process_entry() can correctly handle all subpaths of the D/F conflict. In the case of D->F conversions, it will correctly delete all non-conflicting files below the relevant directory and the directory itself (note that both untracked and conflicting files below the directory will prevent its removal). So if we handle D/F conflicts after all other conflicts, they become fairly simple to handle -- we just need to check for whether or not a path (file/directory) is in the way of creating the new content. We do this by having process_entry() defer handling such entries to a subsequent process_df_entry() step. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-07Implement automatic fast-forward merge for submodulesLibravatar Heiko Voigt1-3/+6
This implements a simple merge strategy for submodule hashes. We check whether one side of the merge candidates is already contained in the other and then merge automatically. If both sides contain changes we search for a merge in the submodule. In case a single one exists we check that out and suggest it as the merge resolution. A list of candidates is returned when we find multiple merges that contain both sides of the changes. This is useful for a workflow in which the developers can publish topic branches in submodules and a separate maintainer merges them. In case the developers always wait until their branch gets merged before tracking them in the superproject all merges of branches that contain submodule changes will be resolved automatically. If developers choose to track their feature branch the maintainer might get a conflict but git will search the submodule for a merge and suggest it/them as a resolution. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05string_list: Add STRING_LIST_INIT macro and make use of it.Libravatar Thiago Farina1-1/+2
Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-02Try normalizing files to avoid delete/modify conflicts when mergingLibravatar Eyvind Bernhardsen1-2/+49
If a file is modified due to normalization on one branch, and deleted on another, a merge of the two branches will result in a delete/modify conflict for that file even if it is otherwise unchanged. Try to avoid the conflict by normalizing and comparing the "base" file and the modified file when their sha1s differ. If they compare equal, the file is considered unmodified and is deleted. Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_lookupLibravatar Julian Phillips1-4/+4
Update the definition and callers of string_list_lookup to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_insertLibravatar Julian Phillips1-8/+8
Update the definition and callers of string_list_insert to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-22Merge branch 'pc/remove-warn' into maintLibravatar Junio C Hamano1-1/+1
* pc/remove-warn: Remove a redundant errno test in a usage of remove_path Introduce remove_or_warn function Implement the rmdir_or_warn function Generalise the unlink_or_warn function
2010-05-08Merge branch 'pc/remove-warn'Libravatar Junio C Hamano1-1/+1
* pc/remove-warn: Remove a redundant errno test in a usage of remove_path Introduce remove_or_warn function Implement the rmdir_or_warn function Generalise the unlink_or_warn function
2010-03-28Remove a redundant errno test in a usage of remove_pathLibravatar Peter Collingbourne1-1/+1
The errno test is redundant because the same test is carried out in remove_path itself. Signed-off-by: Peter Collingbourne <peter@pcc.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-20merge-recursive: add a label for ancestorLibravatar Jonathan Nieder1-0/+1
git merge-recursive (and hence git merge) will present conflict hunks in output something like what ‘diff3 -m’ produces if the merge.conflictstyle configuration option is set to diff3. There is a small difference from diff3: diff3 -m includes a label for the merge base on the ||||||| line. Tools familiar with the format and humans unfamiliar with the format both can benefit from such a label. So mark the start of the text from the merge bases with the heading "||||||| merged common ancestors". It would be nicer to use a more informative label. Perhaps someone will provide one some day. git rerere does not have trouble parsing the new output, and its preimage ids are unchanged since it has its own code for re-creating conflict hunks. No other code in git parses conflict hunks. 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-03-20merge_trees(): add ancestor label parameter for diff3-style outputLibravatar Jonathan Nieder1-3/+8
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-03-20ll_merge(): add ancestor label parameter for diff3-style outputLibravatar Jonathan Nieder1-1/+1
Commands using the ll_merge() function will present conflict hunks imitating ‘diff3 -m’ output if the merge.conflictstyle configuration option is set appropriately. Unlike ‘diff3 -m’, the output does not include a label for the merge base on the ||||||| line of the output, and some tools misparse the conflict hunks without that. Add a new ancestor_label parameter to ll_merge() to give callers the power to rectify this situation. If ancestor_label is NULL, the output format is unchanged. All callers pass NULL for now. 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-02-17refactor duplicated fill_mm() in checkout and merge-recursiveLibravatar Michael Lukashov1-20/+3
The following function is duplicated: fill_mm Move it to xdiff-interface.c and rename it 'read_mmblob', as suggested by Junio C Hamano. Also, change parameters order for consistency with read_mmfile(). Signed-off-by: Michael Lukashov <michael.lukashov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-21Merge branch 'maint'Libravatar Junio C Hamano1-4/+4
* maint: merge-recursive: do not return NULL only to cause segfault retry request without query when info/refs?query fails
2010-01-21merge-recursive: do not return NULL only to cause segfaultLibravatar Junio C Hamano1-4/+4
merge-recursive calls write_tree_from_memory() to come up with a virtual tree, with possible conflict markers inside the blob contents, while merging multiple common ancestors down. It is a bug to call the function with unmerged entries in the index, even if the merge to come up with the common ancestor resulted in conflicts. Otherwise the result won't be expressible as a tree object. We _might_ want to suggest the user to set GIT_MERGE_VERBOSITY to 5 and re-run the merge in the message. At least we will know which part of process_renames() or process_entry() functions is not correctly handling the unmerged paths, and it might help us diagnosing the issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'ap/merge-backend-opts'Libravatar Junio C Hamano1-10/+29
* 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-9/+11
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-2/+19
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-30Merge branch 'mm/maint-merge-ff-error-message-fix'Libravatar Junio C Hamano1-18/+23
Conflicts: merge-recursive.c
2009-11-29merge-recursive: make the error-message generation an extern functionLibravatar Matthieu Moy1-13/+18
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>
2009-11-23Merge branch 'mm/maint-hint-failed-merge'Libravatar Junio C Hamano1-1/+7
* mm/maint-hint-failed-merge: user-manual: Document that "git merge" doesn't like uncommited changes. merge-recursive: point the user to commit when file would be overwritten.
2009-11-22merge-recursive: point the user to commit when file would be overwritten.Libravatar Matthieu Moy1-1/+7
The commit-before-pull is well accepted in the DVCS community, but is confusing some new users. This should get them back in the right way when the problem occurs. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15Check the format of more printf-type functionsLibravatar Tarmigan Casebolt1-1/+3
We already have these checks in many printf-type functions that have prototypes which are in header files. Add these same checks to some more prototypes in header functions and to static functions in .c files. cc: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-08merge-recursive: give less scary messages when merge did not startLibravatar Junio C Hamano1-4/+21
When unpack_trees() three-way merge logic is called from merge-recursive and finds that local changes are going to be clobbered, its plumbing level messages were given as errors first, and then the merge driver added even more scary message "fatal: merging of trees <a long object name> and <another long object name> failed". This is most often encountered by new CVS/SVN migrants who are used to start a merge from a dirty work tree. The saddest part is that the merge refused to run to prevent _any_ damage from being done to your work tree when these messages are given, but the messages look a lot more scarier than the conflicted case where the user needs to resolve them. Replace the plumbing level messages so that they talk about what it is protecting the user from, and end the messages with "Aborting." so that it becomes clear that the command did not do any harm. The final "merging of trees failed" message is superfluous, unless you are interested in debugging the merge-recursive itself. Squelch the current die() message by default, but allow it to help people who debug git with verbosity level 4 or greater. Unless there is some bug, an inner merge that does not touch working tree should not trigger any such error, so emit the current die() message when we see an error return from it while running the inner merge, too. It would also help people who debug git. We could later add instructions on how to recover (i.e. "stash changes away or commit on a side branch and retry") instead of the silent exit(128) I have in this patch, and then use Peff's advice.* mechanism to squelch it (e.g. "advice.mergeindirtytree"), but they are separate topics. Tested-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>