aboutsummaryrefslogtreecommitdiff
path: root/builtin/merge-file.c
Commit message (Collapse)AuthorAge
* Merge branch 'jk/merge-file-exit-code'Junio C Hamano2015-10-30
|\ | | | | | | | | | | | | | | "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
| * merge-file: clamp exit code to maximum 127Jeff King2015-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Sync with 2.3.10Junio C Hamano2015-09-28
|\ \
| * | merge-file: enforce MAX_XDIFF_SIZE on incoming filesJeff King2015-09-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit enforces MAX_XDIFF_SIZE at the interfaces to xdiff: xdi_diff (which calls xdl_diff) and ll_xdl_merge (which calls xdl_merge). But we have another direct call to xdl_merge in merge-file.c. If it were written today, this probably would just use the ll_merge machinery. But it predates that code, and uses slightly different options to xdl_merge (e.g., ZEALOUS_ALNUM). We could try to abstract out an xdi_merge to match the existing xdi_diff, but even that is difficult. Rather than simply report error, we try to treat large files as binary, and that distinction would happen outside of xdi_merge. The simplest fix is to just replicate the MAX_XDIFF_SIZE check in merge-file.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'ab/merge-file-prefix'Junio C Hamano2015-02-22
|\ \ \ | |/ / | | | | | | | | | | | | | | | "git merge-file" did not work correctly in a subdirectory. * ab/merge-file-prefix: merge-file: correctly open files when in a subdir
| * | merge-file: correctly open files when in a subdirAleksander Boruch-Gruszecki2015-02-11
| |/ | | | | | | | | | | | | | | | | | | | | | | | | run_setup_gently() is called before merge-file. This may result in changing current working directory, which wasn't taken into account when opening a file for writing. Fix by prepending the passed prefix. Previous var is left so that error messages keep referring to the file from the user's working directory perspective. Signed-off-by: Aleksander Boruch-Gruszecki <aleksander.boruchgruszecki@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | standardize usage info string formatAlex Henrie2015-01-14
|/ | | | | | | | | | | | | | | This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller2013-08-05
| | | | | | | | | | | | This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* i18n: merge-file: mark parseopt strings for translationNguyễn Thái Ngọc Duy2012-08-20
| | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* remove superfluous newlines in error messagesPete Wyckoff2012-04-30
| | | | | | | | The error handling routines add a newline. Remove the duplicate ones in error messages. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'rs/opt-help-text'Junio C Hamano2010-11-24
|\ | | | | | | | | | | | | | | | | | | | | | | * rs/opt-help-text: verify-tag: document --verbose branch: improve --verbose description archive: improve --verbose description Describe various forms of "be quiet" using OPT__QUIET add OPT__FORCE add description parameter to OPT__QUIET add description parameter to OPT__DRY_RUN add description parameter to OPT__VERBOSE
| * Describe various forms of "be quiet" using OPT__QUIETJonathan Nieder2010-11-15
| | | | | | | | | | Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * add description parameter to OPT__QUIETRené Scharfe2010-11-15
| | | | | | | | | | | | | | | | | | Allows better help text to be defined than "be quiet". Also make use of the macro in a place that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | merge-file: correctly find files when called in subdirThomas Rast2010-10-18
|/ | | | | | | | | | | | | | | Since b541248 (merge.conflictstyle: choose between "merge" and "diff3 -m" styles, 2008-08-29), git-merge-file uses setup_directory_gently(), thus cd'ing around to find any possible config files to use. This broke merge-file when it is called from within a subdirectory of a repository, and the arguments are all relative paths. Fix by prepending the prefix, as passed down from the main git setup code, if there is any. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* merge-file: run setup_git_directory_gently() soonerNguyễn Thái Ngọc Duy2010-08-15
| | | | | | | | | | | Part of a campaign to make repository-local configuration available early (simplifying the startup sequence for built-in commands). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'rs/diff-no-minimal'Junio C Hamano2010-06-13
| | | | | * rs/diff-no-minimal: git diff too slow for a file
* merge-file --diff3: add a label for ancestorJonathan Nieder2010-03-20
| | | | | | | | | | | | | | | | | | | | | | git merge-file --diff3 can be used to present conflicts hunks including text from the common ancestor. The added information is helpful for resolving a merge by hand, and merge tools can usually grok it because it looks like output from diff3 -m. However, ‘diff3’ includes a label for the merge base on the ||||||| line and some tools cannot parse conflict hunks without such a label. Write the base-name as passed in a -L option (or the name of the ancestor file by default) on that line. git rerere will not have trouble parsing this output, since instead of looking for a newline, it looks for whitespace after the ||||||| marker. Since rerere includes its own code for recreating conflict hunks, conflict identifiers are unaffected. No other code in git tries to parse 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>
* xdl_merge(): move file1 and file2 labels to xmparam structureJonathan Nieder2010-03-20
| | | | | | | | | | | | | | The labels for the three participants in a potential conflict are all optional arguments for the xdiff merge routine; if they are NULL, then xdl_merge() can cope by omitting the labels from its output. Move them to the xmparam structure to allow new callers to save some keystrokes where they are not needed. This also has the virtue of making the xdiff merge interface more similar to merge_trees, which might make it easier to learn. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'bw/union-merge-refactor'Junio C Hamano2010-03-20
| | | | | | | | * bw/union-merge-refactor: merge-file: add option to select union merge favor merge-file: add option to specify the marker size refactor merge flags into xmparam_t make union merge an xdl merge favor
* Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds2010-02-22
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>