summaryrefslogtreecommitdiff
path: root/rerere.c
AgeCommit message (Collapse)AuthorFilesLines
2011-05-30Merge branch 'maint'Libravatar Junio C Hamano1-2/+8
* maint: git-submodule.sh: separate parens by a space to avoid confusing some shells Documentation/technical/api-diff.txt: correct name of diff_unmerge() read_gitfile_gently: use ssize_t to hold read result remove tests of always-false condition rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-30Merge branch 'jm/maint-misc-fix' into maintLibravatar Junio C Hamano1-2/+8
* jm/maint-misc-fix: read_gitfile_gently: use ssize_t to hold read result remove tests of always-false condition rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-26plug a DIR buffer leak in rerere.cLibravatar Jim Meyering1-0/+1
Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'Libravatar Jim Meyering1-2/+8
If we reach EOF after the SHA1-then-TAB, yet before the NUL that terminates each file name, we would fill the file name buffer with \255 bytes resulting from the repeatedly-failing fgetc (returns EOF/-1) and ultimately complain about "filename too long", because no NUL was encountered. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-08rerere: libify rerere_clear() and rerere_gc()Libravatar Junio C Hamano1-0/+84
This moves the two features from builtin/rerere.c to a more library-ish portion of the codebase. No behaviour change. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-03sparse: Fix errors and silence warningsLibravatar Stephen Boyd1-1/+1
* load_file() returns a void pointer but is using 0 for the return value * builtin/receive-pack.c forgot to include builtin.h * packet_trace_prefix can be marked static * ll_merge takes a pointer for its last argument, not an int * crc32 expects a pointer as the second argument but Z_NULL is defined to be 0 (see 38f4d13 sparse fix: Using plain integer as NULL pointer, 2006-11-18 for more info) Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-26Merge branch 'jc/maint-rerere-in-workdir'Libravatar Junio C Hamano1-2/+1
* jc/maint-rerere-in-workdir: rerere: make sure it works even in a workdir attached to a young repository
2011-03-23rerere: make sure it works even in a workdir attached to a young repositoryLibravatar Junio C Hamano1-2/+1
The git-new-workdir script in contrib/ makes a new work tree by sharing many subdirectories of the .git directory with the original repository. When rerere.enabled is set in the original repository, but the user has not encountered any conflicts yet, the original repository may not yet have .git/rr-cache directory. When rerere wants to run in a new work tree created from such a young original repository, it fails to mkdir(2) .git/rr-cache that is a symlink to a yet-to-be-created directory. There are three possible approaches to this: - A naive solution is not to create a symlink in the git-new-workdir script to a directory the original does not have (yet). This is not a solution, as we tend to lazily create subdirectories of .git/, and having rerere.enabled configuration set is a strong indication that the user _wants_ to have this lazy creation to happen; - We could always create .git/rr-cache upon repository creation. This is tempting but will not help people with existing repositories. - Detect this case by seeing that mkdir(2) failed with EEXIST, checking that the path is a symlink, and try running mkdir(2) on the link target. This patch solves the issue by doing the third one. Strictly speaking, this is incomplete. It does not attempt to handle relative symbolic link that points into the original repository, but this is good enough to help people who use contrib/workdir/git-new-workdir script. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-16rerere "remaining"Libravatar Martin von Zweigbergk1-10/+68
After "rerere" resolves conflicts by reusing old resolution, there would be three kinds of paths with conflict in the index: * paths that have been resolved in the working tree by rerere; * paths that need further work whose resolution could be recorded; * paths that need resolving that rerere won't help. When the user wants a list of paths that need hand-resolving, output from "rerere status" does not help, as it shows only the second category, but the paths in the third category still needs work (rerere only makes sense for regular files that have both our side and their side, and does not help other kinds of conflicts, e.g. "we modified, they deleted"). The new subcommand "rerere remaining" can be used to show both. As opposed to "rerere status", this subcommand also skips printing paths that have been added to the index, since these paths are already resolved and are no longer "remaining". Initial patch provided by Junio. Refactored and modified to skip resolved paths by Martin. Commit message mostly by Junio. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-26Merge branch 'jf/merge-ignore-ws'Libravatar Junio C Hamano1-1/+1
* 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-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-26ll-merge: replace flag argument with options structLibravatar Jonathan Nieder1-1/+1
Keeping track of the flag bits is proving more trouble than it's worth. Instead, use a pointer to an options struct like most similar APIs do. Callers with no special requests can pass NULL to request the default options. Cc: Bert Wesarg <bert.wesarg@googlemail.com> Cc: Avery Pennarun <apenwarr@gmail.com> Helped-by: Justin Frankel <justin@cockos.com> Helped-by: 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-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>