summaryrefslogtreecommitdiff
path: root/rerere.c
AgeCommit message (Collapse)AuthorFilesLines
2010-09-03Merge branch 'jn/merge-renormalize'Libravatar Junio C Hamano1-0/+4
* 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-08-31Merge branch 'sg/rerere-gc-old-still-used'Libravatar Junio C Hamano1-1/+7
* sg/rerere-gc-old-still-used: rerere: fix overeager gc mingw_utime(): handle NULL times parameter
2010-08-06rerere: never renormalizeLibravatar Jonathan Nieder1-6/+5
plain rerere performs three tasks; let us consider how the new merge.renormalize option should apply to each. After an unsuccessful merge, rerere records conflict hunks from the work tree under .git/rr-cache. If the merge was performed with merge.renormalize enabled, both sides of the conflict hunk use the current work tree’s end-of-line and smudge rules; there is not really much of a choice. After a successful manual resolution, rerere records the postimage. Here, also, the file will be in the current work tree’s canonical format and there is not much to do about it. When encountering that conflict again, merge looks up the preimage and postimage using the conflict hunk as a key and runs a three-way merge to apply that resolution to the work tree. Since the conflict hunk used the current work tree’s canonical format, chances are the version in the work tree, the preimage, and the postimage will, too. In fact using the merge.renormalize machinery is exactly the wrong thing to do, since its result has been run through convert_to_git and therefore is not suitable for writing to the work tree. The only affected caller is "git merge". NEEDSWORK: lacks test 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-5/+10
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-07-14rerere: fix overeager gcLibravatar SZEDER Gábor1-1/+7
'rerere gc' prunes resolutions of conflicted merges that occurred long time ago, and when doing so it takes the creation time of the conflicted automerge results into account. This can cause the loss of frequently used conflict resolutions (e.g. long-living topic branches are merged into a regularly rebuilt integration branch (think of git's pu)) when they become old enough to exceed 'rerere gc's threshold. To prevent the loss of valuable merge resolutions 'rerere' will (1) update the timestamp of the recorded conflict resolution (i.e. 'postimage') each time when encountering and resolving the same merge conflict, and (2) take this timestamp, i.e. the time of the last usage into account when gc'ing. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> 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-5/+5
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-06-30Merge branch 'jp/string-list-api-cleanup'Libravatar Junio C Hamano1-5/+5
* jp/string-list-api-cleanup: string_list: Fix argument order for string_list_append string_list: Fix argument order for string_list_lookup string_list: Fix argument order for string_list_insert_at_index string_list: Fix argument order for string_list_insert string_list: Fix argument order for for_each_string_list string_list: Fix argument order for print_string_list
2010-06-27string_list: Fix argument order for string_list_insertLibravatar Julian Phillips1-5/+5
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-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-03-20ll_merge(): add ancestor label parameter for diff3-style outputLibravatar Jonathan Nieder1-2/+2
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-23rerere: fix memory leak if rerere images can't be readLibravatar Bert Wesarg1-3/+6
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28rerere: fix too-short initializationLibravatar Jeff King1-1/+1
This was caused by a typo in the sizeof parameter, and meant we looked at uninitialized memory. Caught by valgrind in t2030. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'jc/conflict-marker-size'Libravatar Junio C Hamano1-14/+46
* jc/conflict-marker-size: rerere: honor conflict-marker-size attribute rerere: prepare for customizable conflict marker length conflict-marker-size: new attribute rerere: use ll_merge() instead of using xdl_merge() merge-tree: use ll_merge() not xdl_merge() xdl_merge(): allow passing down marker_size in xmparam_t xdl_merge(): introduce xmparam_t for merge specific parameters git_attr(): fix function signature Conflicts: builtin-merge-file.c ll-merge.c xdiff/xdiff.h xdiff/xmerge.c
2010-01-20Merge branch 'jc/cache-unmerge'Libravatar Junio C Hamano1-42/+217
* jc/cache-unmerge: rerere forget path: forget recorded resolution rerere: refactor rerere logic to make it independent from I/O rerere: remove silly 1024-byte line limit resolve-undo: teach "update-index --unresolve" to use resolve-undo info resolve-undo: "checkout -m path" uses resolve-undo information resolve-undo: allow plumbing to clear the information resolve-undo: basic tests resolve-undo: record resolved conflicts in a new index extension section builtin-merge.c: use standard active_cache macros Conflicts: builtin-ls-files.c builtin-merge.c builtin-rerere.c
2010-01-17rerere: honor conflict-marker-size attributeLibravatar Junio C Hamano1-2/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-17rerere: prepare for customizable conflict marker lengthLibravatar Junio C Hamano1-10/+44
This still uses the hardcoded conflict marker length of 7 but otherwise prepares the codepath to deal with customized marker length. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16rerere: use ll_merge() instead of using xdl_merge()Libravatar Junio C Hamano1-4/+1
This allows us to pay attention to the attribute settings and custom merge driver the user sets up. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-16xdl_merge(): introduce xmparam_t for merge specific parametersLibravatar Junio C Hamano1-2/+2
So far we have only needed to be able to pass an option that is generic to xdiff family of functions to this function. Extend the interface so that we can give it merge specific parameters. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10rerere forget path: forget recorded resolutionLibravatar Junio C Hamano1-0/+133
After you find out an earlier resolution you told rerere to use was a mismerge, there is no easy way to clear it. A new subcommand "forget" can be used to tell git to forget a recorded resolution, so that you can redo the merge from scratch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10rerere: refactor rerere logic to make it independent from I/OLibravatar Junio C Hamano1-35/+76
This splits the handle_file() function into in-core part and I/O parts of the logic to create the preimage, so that we can compute the conflict identifier without having to use temporary files. Earlier, I thought the output from handle_file() should also be refactored, but it is always about writing preimage (or thisimage) that is used for later three-way merge, so it is saner to keep it to always write to FILE *. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25rerere: remove silly 1024-byte line limitLibravatar Junio C Hamano1-9/+10
Ever since 658f365 (Make git-rerere a builtin, 2006-12-20) rewrote it, it kept this line-length limit regression, even after we started using strbuf in the same function in 19b358e (Use strbuf API in buitin-rerere.c, 2007-09-06). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-04Teach --[no-]rerere-autoupdate option to merge, revert and friendsLibravatar Junio C Hamano1-3/+5
Introduce a command line option to override rerere.autoupdate configuration variable to make it more useful. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13use write_str_in_full helper to avoid literal string lengthsLibravatar Jim Meyering1-1/+1
In 2d14d65 (Use a clearer style to issue commands to remote helpers, 2009-09-03) I happened to notice two changes like this: - write_in_full(helper->in, "list\n", 5); + + strbuf_addstr(&buf, "list\n"); + write_in_full(helper->in, buf.buf, buf.len); + strbuf_reset(&buf); IMHO, it would be better to define a new function, static inline ssize_t write_str_in_full(int fd, const char *str) { return write_in_full(fd, str, strlen(str)); } and then use it like this: - strbuf_addstr(&buf, "list\n"); - write_in_full(helper->in, buf.buf, buf.len); - strbuf_reset(&buf); + write_str_in_full(helper->in, "list\n"); Thus not requiring the added allocation, and still avoiding the maintenance risk of literal string lengths. These days, compilers are good enough that strlen("literal") imposes no run-time cost. Transformed via this: perl -pi -e \ 's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\ $(git grep -l 'write_in_full.*"') Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-29replace direct calls to unlink(2) with unlink_or_warnLibravatar Alex Riesen1-1/+1
This helps to notice when something's going wrong, especially on systems which lock open files. I used the following criteria when selecting the code for replacement: - it was already printing a warning for the unlink failures - it is in a function which already printing something or is called from such a function - it is in a static function, returning void and the function is only called from a builtin main function (cmd_) - it is in a function which handles emergency exit (signal handlers) - it is in a function which is obvously cleaning up the lockfiles Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14rerere: remove duplicated functionsLibravatar SZEDER Gábor1-11/+11
Both rerere.c and builtin-rerere.c define the static functions rr_path() and has_resolution() the exact same way. To eliminate this code duplication this patch turns the functions in rerere.c non-static, and makes builtin-rerere.c use them. Also, since this puts these two functions into the global namespace, rename them to rerere_path() and has_rerere_resolution(), respectively, and rename their "name" parameter to "hex", because it better reflects what that parameter actually is. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-10Drop double-semicolon in CLibravatar Junio C Hamano1-1/+1
The worst offenders are "continue;;" and "break;;" in switch statements. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-04Make some of fwrite/fclose/write/close failures visibleLibravatar Alex Riesen1-11/+35
So that full filesystem conditions or permissions problems won't go unnoticed. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-30Merge branch 'ar/maint-mksnpath' into ar/mksnpathLibravatar Junio C Hamano1-1/+1
* ar/maint-mksnpath: Use git_pathdup instead of xstrdup(git_path(...)) git_pathdup: returns xstrdup-ed copy of the formatted path Fix potentially dangerous use of git_path in ref.c Add git_snpath: a .git path formatting routine with output buffer Conflicts: builtin-revert.c refs.c rerere.c
2008-10-30Use git_pathdup instead of xstrdup(git_path(...))Libravatar Alex Riesen1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-21Merge branch 'jc/maint-co-track'Libravatar Junio C Hamano1-1/+2
* jc/maint-co-track: Enhance hold_lock_file_for_{update,append}() API demonstrate breakage of detached checkout with symbolic link HEAD Fix "checkout --track -b newbranch" on detached HEAD Conflicts: builtin-commit.c
2008-10-19Enhance hold_lock_file_for_{update,append}() APILibravatar Junio C Hamano1-1/+2
This changes the "die_on_error" boolean parameter to a mere "flags", and changes the existing callers of hold_lock_file_for_update/append() functions to pass LOCK_DIE_ON_ERROR. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-3/+1
Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-02fix openssl headers conflicting with custom SHA1 implementationsLibravatar Nicolas Pitre1-5/+5
On ARM I have the following compilation errors: CC fast-import.o In file included from cache.h:8, from builtin.h:6, from fast-import.c:142: arm/sha1.h:14: error: conflicting types for 'SHA_CTX' /usr/include/openssl/sha.h:105: error: previous declaration of 'SHA_CTX' was here arm/sha1.h:16: error: conflicting types for 'SHA1_Init' /usr/include/openssl/sha.h:115: error: previous declaration of 'SHA1_Init' was here arm/sha1.h:17: error: conflicting types for 'SHA1_Update' /usr/include/openssl/sha.h:116: error: previous declaration of 'SHA1_Update' was here arm/sha1.h:18: error: conflicting types for 'SHA1_Final' /usr/include/openssl/sha.h:117: error: previous declaration of 'SHA1_Final' was here make: *** [fast-import.o] Error 1 This is because openssl header files are always included in git-compat-util.h since commit 684ec6c63c whenever NO_OPENSSL is not set, which somehow brings in <openssl/sha1.h> clashing with the custom ARM version. Compilation of git is probably broken on PPC too for the same reason. Turns out that the only file requiring openssl/ssl.h and openssl/err.h is imap-send.c. But only moving those problematic includes there doesn't solve the issue as it also includes cache.h which brings in the conflicting local SHA1 header file. As suggested by Jeff King, the best solution is to rename our references to SHA1 functions and structure to something git specific, and define those according to the implementation used. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-29Merge branch 'jc/better-conflict-resolution'Libravatar Shawn O. Pearce1-10/+19
* jc/better-conflict-resolution: Fix AsciiDoc errors in merge documentation git-merge documentation: describe how conflict is presented checkout --conflict=<style>: recreate merge in a non-default style checkout -m: recreate merge when checking out of unmerged index git-merge-recursive: learn to honor merge.conflictstyle merge.conflictstyle: choose between "merge" and "diff3 -m" styles rerere: understand "diff3 -m" style conflicts with the original rerere.c: use symbolic constants to keep track of parsing states xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or less xmerge.c: minimum readability fixups xdiff-merge: optionally show conflicts in "diff3 -m" style xdl_fill_merge_buffer(): separate out a too deeply nested function checkout --ours/--theirs: allow checking out one side of a conflicting merge checkout -f: allow ignoring unmerged paths when checking out of the index Conflicts: Documentation/git-checkout.txt builtin-checkout.c builtin-merge-recursive.c t/t7201-co.sh
2008-09-09is_directory(): a generic helper functionLibravatar Junio C Hamano1-2/+1
A simple "grep -e stat --and -e S_ISDIR" revealed there are many open-coded implementations of this function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30rerere: understand "diff3 -m" style conflicts with the originalLibravatar Junio C Hamano1-2/+8
This teaches rerere to grok conflicts expressed in "diff3 -m" style output, where the version from the common ancestor is output after the first side, preceded by a "|||||||" line. The rerere database needs to keep only the versions from two sides, so the code parses the original copy and discards it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30rerere.c: use symbolic constants to keep track of parsing statesLibravatar Junio C Hamano1-10/+13
These hardcoded integers make the code harder to follow than necessary; replace them with enums to make it easier to read, before adding support for optionally parsing "diff3 -m" style conflict markers. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21Rename path_list to string_listLibravatar Johannes Schindelin1-20/+20
The name path_list was correct for the first usage of that data structure, but it really is a general-purpose string list. $ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list) $ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list) $ git mv path-list.h string-list.h $ git mv path-list.c string-list.c $ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path) $ perl -i -pe 's/path/string/g' string-list.[ch] $ git mv Documentation/technical/api-path-list.txt \ Documentation/technical/api-string-list.txt $ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths) ... and then fix all users of string-list to access the member "string" instead of "path". Documentation/technical/api-string-list.txt needed some rewrapping, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-16rerere.autoupdate: change the message when autoupdate is in effectLibravatar Junio C Hamano1-2/+5
This changes the message rerere issues after reusing previous conflict resolution from "Resolved" to "Staged" when autoupdate option is in effect. It is envisioned that in practice, some auto resolitions are trickier and iffier than others, and we would want to add a feature to mark individual resolutions as "this is ok to autoupdate" or "do not autoupdate the result using this resolution even when rerere.autoupdate is in effect" in the future. When that happens, these messages will make the distinction clearer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-14Merge branch 'js/merge-rr'Libravatar Junio C Hamano1-1/+1
* js/merge-rr: Move MERGE_RR from .git/rr-cache/ into .git/ Conflicts: builtin-rerere.c
2008-07-10rerere: Separate libgit and builtin functionsLibravatar Stephan Beyer1-0/+360
This patch moves rerere()-related functions into a newly created rerere.c file. The setup_rerere() function is needed by both rerere() and cmd_rerere(), so this function is moved to rerere.c and declared non-static (and "extern") in newly created rerere.h file. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>