summaryrefslogtreecommitdiff
path: root/diff.c
AgeCommit message (Collapse)AuthorFilesLines
2006-02-26Make git diff-generation use a simpler spawn-like interfaceLibravatar Linus Torvalds1-58/+80
Instead of depending of fork() and execve() and doing things in between the two, make the git diff functions do everything up front, and then do a single "spawn_prog()" invocation to run the actual external diff program (if any is even needed). This actually ends up simplifying the code, and should make it much easier to make it efficient under broken operating systems (read: Windows). Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-21Merge branch 'jc/nostat'Libravatar Junio C Hamano1-1/+1
* jc/nostat: cache_name_compare() compares name and stage, nothing else. "assume unchanged" git: documentation. ls-files: split "show-valid-bit" into a different option. "Assume unchanged" git: --really-refresh fix. ls-files: debugging aid for CE_VALID changes. "Assume unchanged" git: do not set CE_VALID with --refresh "Assume unchanged" git
2006-02-10find_unique_abbrev() simplification.Libravatar Junio C Hamano1-11/+3
Earlier it did not grok the 0{40} SHA1 very well, but what it needed to do was to find the shortest 0{N} that is not used as a valid object name to be consistent with the way names of valid objects are abbreviated. This makes some users simpler. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-08"Assume unchanged" gitLibravatar Junio C Hamano1-1/+1
This adds "assume unchanged" logic, started by this message in the list discussion recently: <Pine.LNX.4.64.0601311807470.7301@g5.osdl.org> This is a workaround for filesystems that do not have lstat() that is quick enough for the index mechanism to take advantage of. On the paths marked as "assumed to be unchanged", the user needs to explicitly use update-index to register the object name to be in the next commit. You can use two new options to update-index to set and reset the CE_VALID bit: git-update-index --assume-unchanged path... git-update-index --no-assume-unchanged path... These forms manipulate only the CE_VALID bit; it does not change the object name recorded in the index file. Nor they add a new entry to the index. When the configuration variable "core.ignorestat = true" is set, the index entries are marked with CE_VALID bit automatically after: - update-index to explicitly register the current object name to the index file. - when update-index --refresh finds the path to be up-to-date. - when tools like read-tree -u and apply --index update the working tree file and register the current object name to the index file. The flag is dropped upon read-tree that does not check out the index entry. This happens regardless of the core.ignorestat settings. Index entries marked with CE_VALID bit are assumed to be unchanged most of the time. However, there are cases that CE_VALID bit is ignored for the sake of safety and usability: - while "git-read-tree -m" or git-apply need to make sure that the paths involved in the merge do not have local modifications. This sacrifices performance for safety. - when git-checkout-index -f -q -u -a tries to see if it needs to checkout the paths. Otherwise you can never check anything out ;-). - when git-update-index --really-refresh (a new flag) tries to see if the index entry is up to date. You can start with everything marked as CE_VALID and run this once to drop CE_VALID bit for paths that are modified. Most notably, "update-index --refresh" honours CE_VALID and does not actively stat, so after you modified a file in the working tree, update-index --refresh would not notice until you tell the index about it with "git-update-index path" or "git-update-index --no-assume-unchanged path". This version is not expected to be perfect. I think diff between index and/or tree and working files may need some adjustment, and there probably needs other cases we should automatically unmark paths that are marked to be CE_VALID. But the basics seem to work, and ready to be tested by people who asked for this feature. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-01Allow diff and index commands to be interruptedLibravatar Petr Baudis1-0/+2
So far, e.g. git-update-index --refresh was basically uninterruptable by ctrl-c, since it hooked the SIGINT handler, but that handler would only unlink the lockfile but not actually quit. This makes it propagate the signal to the default handler. Note that I expected it to work without resetting the signal handler to SIG_DFL, but without that it ended in an infinite loop of tgkill()s - is my glibc violating SUS or what? Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28diff --abbrev=<n> option fix.Libravatar Junio C Hamano1-1/+6
Earier specifying an abbreviation shorter than minimum fell back to full 40 letters, which was nonsense. Make it to fall back to the minimum number (currently 4). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28abbrev cleanup: use symbolic constantsLibravatar Junio C Hamano1-2/+2
The minimum length of abbreviated object name was hardcoded in different places to be 4, risking inconsistencies in the future. Also there were three different "default abbreviation precision". Use two C preprocessor symbols to clean up this mess. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-29code comments: spellLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26Handle symlinks graciouslyLibravatar Johannes Schindelin1-1/+1
This patch converts a stat() to an lstat() call, thereby fixing the case when the date of a symlink was not the same as the one recorded in the index. The included test case demonstrates this. This is for the case that the symlink points to a non-existing file. If the file exists, worse things than just an error message happen. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26avoid asking ?alloc() for zero bytes.Libravatar Junio C Hamano1-3/+3
Avoid asking for zero bytes when that change simplifies overall logic. Later we would change the wrapper to ask for 1 byte on platforms that return NULL for zero byte request. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-19diff: --abbrev optionLibravatar Junio C Hamano1-6/+51
When I show transcripts to explain how something works, I often find myself hand-editing the diff-raw output to shorten various object names in the output. This adds --abbrev option to the diff family, which shortens diff-raw output and diff-tree commit id headers. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21Move diff.renamelimit out of default configuration.Libravatar Junio C Hamano1-0/+10
Otherwise we would end up linking all the unneeded stuff into git-daemon only to link with git_default_config. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21rename/copy score parsing updates.Libravatar H. Peter Anvin1-12/+21
Better variant, which handles stuff like "4.5%" and rejects "192.168.0.1". Additionally, make sure numbers are unsigned (I'm making them unsigned long just for the hell of it), to make sure that artificial wraparound scenarios don't cause harm. -hpa [jc: with this, -M100 changes its meaning back to 10%. People wanting to say "pure renames only" should now say -M100% or -M1.0; sounds a bit like an earthquake, but arguably things are more consistent this way ;-)] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21rename detection with -M100 means "exact renames only".Libravatar Junio C Hamano1-0/+4
When the user is interested in pure renames, there is no point doing the similarity scores. This changes the score argument parsing to special case -M100 (otherwise, it is a precision scaled value 0 <= v < 1 and would mean 0.1, not 1.0 --- if you do mean 0.1, you can say -M1), and optimizes the diffcore_rename transformation to only look at pure renames in that case. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-16diff: --full-indexLibravatar Junio C Hamano1-6/+8
A new option, --full-index, is introduced to diff family. This causes the full object name of pre- and post-images to appear on the index line of patch formatted output, to be used in conjunction with --allow-binary-replacement option of git-apply. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-15diff: make default rename detection limit configurable.Libravatar Junio C Hamano1-2/+7
A while ago, a rename-detection limit logic was implemented as a response to this thread: http://marc.theaimsgroup.com/?l=git&m=112413080630175 where gitweb was found to be using a lot of time and memory to detect renames on huge commits. git-diff family takes -l<num> flag, and if the number of paths that are rename destination candidates (i.e. new paths with -M, or modified paths with -C) are larger than that number, skips rename/copy detection even when -M or -C is specified on the command line. This commit makes the rename detection limit easier to use. You can have: [diff] renamelimit = 30 in your .git/config file to specify the default rename detection limit. You can override this from the command line; giving 0 means 'unlimited': git diff -M -l0 We might want to change the default behaviour, when you do not have the configuration, to limit it to say 20 paths or so. This would also help the diffstat generation after a big 'git pull'. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-22Split up tree diff functions into tree-diff.c libraryLibravatar Linus Torvalds1-0/+3
This makes the tree diff functionality independent of the "git-diff-tree" program, by splitting the core functionality up into a library file. This will be needed for when we teach git-rev-list to only follow a specified set of pathnames, rather than the global revision history. Most of it is a fairly straightforward code move, but it also involves some calling convention cleanup, and moving some of the static variables from diff-tree.c into the options structure. The actual tree change callback routines also become paramterized by the diff_options structure, allowing the library functionality to do something else than just show the diff on stdout. Right now the only user of this functionality remains git-diff-tree itself. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18Handle "-" at beginning of filenames, part 3Libravatar Linus Torvalds1-1/+1
This fixes the default built-in exec() of "diff" to add a "--" before the filenames, so that if a filename starts with a "-", the diff program won't think it's an option. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17Update git-diff-* to use C-style quoting for funny pathnames.Libravatar Junio C Hamano1-40/+95
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-07Show original and resulting blob object info in diff output.Libravatar Junio C Hamano1-20/+57
This adds more cruft to diff --git header to record the blob SHA1 and the mode the patch/diff is intended to be applied against, to help the receiving end fall back on a three-way merge. The new header looks like this: diff --git a/apply.c b/apply.c index 7be5041..8366082 100644 --- a/apply.c +++ b/apply.c @@ -14,6 +14,7 @@ // files that are being modified, but doesn't apply the patch // --stat does just a diffstat, and doesn't actually apply +// --show-index-info shows the old and new index info for... ... Upon receiving such a patch, if the patch did not apply cleanly to the target tree, the recipient can try to find the matching old objects in her object database and create a temporary tree, apply the patch to that temporary tree, and attempt a 3-way merge between the patched temporary tree and the target tree using the original temporary tree as the common ancestor. The patch lifts the code to compute the hash for an on-filesystem object from update-index.c and makes it available to the diff output routine. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-30Consolidate null_sha1[].Libravatar Junio C Hamano1-2/+1
Signed-off-by: Junio C Hamano <junio@twinsun.com>
2005-09-24Diff: --name-status output format.Libravatar Junio C Hamano1-9/+13
The new output format shows only the status letter and paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-24Diff: -l<num> to limit rename/copy detection.Libravatar Junio C Hamano1-2/+5
When many paths are modified, rename detection takes a lot of time. The new option -l<num> can be used to disable rename detection when more than <num> paths are possibly created as renames. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-24Diff clean-up.Libravatar Junio C Hamano1-44/+93
This is a long overdue clean-up to the code for parsing and passing diff options. It also tightens some constness issues. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-22Retire diff-helper.Libravatar Junio C Hamano1-23/+0
The textual diff generation with built-in '-p' in diff-* brothers has proven to be useful enough that git-diff-helper outlived its usefulness. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-15Plug diff leaks.Libravatar Junio C Hamano1-1/+4
It is a bit embarrassing that it took this long for a fix since the problem was first reported on Aug 13th. Message-ID: <87y876gl1r.wl@mail2.atmark-techno.com> From: Yasushi SHOJI <yashi@atmark-techno.com> Newsgroups: gmane.comp.version-control.git Subject: [patch] possible memory leak in diff.c::diff_free_filepair() Date: Sat, 13 Aug 2005 19:58:56 +0900 This time I used valgrind to make sure that it does not overeagerly discard memory that is still being used. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-14Revert "[PATCH] plug memory leak in diff.c::diff_free_filepair()"Libravatar Junio C Hamano1-4/+5
This reverts 068eac91ce04b9aca163acb1927c3878c45d1a07 commit.
2005-09-14[PATCH] Fix alloc_filespec() initializationLibravatar Linus Torvalds1-7/+3
This simplifies and fixes the initialization of a "diff_filespec" when allocated. The old code would not initialize "sha1_valid". Noticed by valgrind. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-10Fix copy marking from diffcore-rename.Libravatar Junio C Hamano1-1/+3
When (A,B) ==> (B,C) rename-copy was detected, we incorrectly said that C was created by copying B. This is because we only check if the path of rename/copy source still exists in the resulting tree to see if the file is renamed out of existence. In this case, the new B is created by copying or renaming A, so the original B is lost and we should say C is a rename of B not a copy of B. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-09Retire support for old environment variables.Libravatar Junio C Hamano1-2/+2
We have deprecated the old environment variable names for quite a while and now it's time to remove them. Gone are: SHA1_FILE_DIRECTORIES AUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Fix compilation warnings.Libravatar Junio C Hamano1-1/+1
... found by compiling them with gcc 2.95. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23Fix ?: statements.Libravatar Jason Riedy1-8/+11
Omitting the first branch in ?: is a GNU extension. Cute, but not supported by other compilers. Replaced mostly by explicit tests. Calls to getenv() simply are repeated on non-GNU compilers. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
2005-08-21[PATCH] possible memory leak in diff.c::diff_free_filepair()Libravatar Yasushi SHOJI1-2/+1
Here is a patch to fix the problem in the simplest way.
2005-08-13[PATCH] plug memory leak in diff.c::diff_free_filepair()Libravatar Yasushi SHOJI1-5/+4
When I run git-diff-tree on big change, it seems the command eats so much memory. so I just put git under valgrind to see what's going on. diff_free_filespec_data() doesn't free diff_filespec itself. [jc: I ended up doing things slightly differently from Yasushi's patch. The original idea was to use free_filespec_data() only to free the data portion and keep useing the filespec itself, but no existing code seems to do things that way, so I just yanked that part out.] Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09A bit more format warning squelching.Libravatar Junio C Hamano1-3/+4
Inspired by patch from Timo Sirainen. Most of them are not strictly necessary but making warnings less chatty would help spot real bugs later. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05[PATCH] git: use git_mkstemp() instead of mkstemp() for diff generation.Libravatar Holger Eitzenberger1-3/+4
This lets you run git diff in a repository otherwise read-only to you. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-29[PATCH] mmap error handlingLibravatar Pavel Roskin1-1/+3
I have reviewed all occurrences of mmap() in git and fixed three types of errors/defects: 1) The result is not checked. 2) The file descriptor is closed if mmap() succeeds, but not when it fails. 3) Various casts applied to -1 are used instead of MAP_FAILED, which is specifically defined to check mmap() return value. [jc: This is a second round of Pavel's patch. He fixed up the problem that close() potentially clobbering the errno from mmap, which the first round had.] Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-25Use symbolic constants for diff-raw status indicators.Libravatar Junio C Hamano1-25/+33
Both Cogito and StGIT prefer to see 'A' for new files. The current 'N' is visually harder to distinguish from 'M', which is used for modified files. Prepare the internals to use symbolic constants to make the change easier. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-14Split up "diff_format" into "format" and "line_termination".Libravatar Linus Torvalds1-8/+4
This removes the separate "formats" for name and name-with-zero- termination. It also removes the difference between HUMAN and MACHINE formats, and they both become DIFF_FORMAT_RAW, with the difference being just in the line and inter-filename termination. It also makes the code easier to understand.
2005-07-13[PATCH] git-diff-*: --name-only and --name-only-z.Libravatar Junio C Hamano1-1/+12
Porcelain layers often want to find only names of changed files, and even with diff-raw output format they end up having to pick out only the filename. Support --name-only (and --name-only-z for xargs -0 and cpio -0 users that want to treat filenames with embedded newlines sanely) flag to help them. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-08[PATCH] Make sq_expand() available as sq_quote().Libravatar Junio C Hamano1-41/+6
A useful shell safety helper sq_expand() was hidden as a static function in diff.c. Extract it out and make it available as sq_quote(). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27[PATCH] Enhance sha1_file_size() into sha1_object_info()Libravatar Junio C Hamano1-1/+1
This lets us eliminate one use of map_sha1_file() outside sha1_file.c, to bring us one step closer to the packed GIT. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-19[PATCH] Rework -B output.Libravatar Junio C Hamano1-70/+159
Patch for a completely rewritten file detected by the -B flag was shown as a pair of creation followed by deletion in earlier versions. This was an misguided attempt to make reviewing such a complete rewrite easier, and unnecessarily ended up confusing git-apply. Instead, show the entire contents of old version prefixed with '-', followed by the entire contents of new version prefixed with '+'. This gives the same easy-to-review for human consumer while keeping it a single, regular modification patch for machine consumption, something that even GNU patch can grok. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] Add --diff-filter= output restriction to diff-* family.Libravatar Junio C Hamano1-4/+66
This is a halfway between debugging aid and a helper to write an ultra-smart merge scripts. The new option takes a string that consists of a list of "status" letters, and limits the diff output to only those classes of changes, with two exceptions: - A broken pair (aka "complete rewrite"), does not match D (deleted) or N (created). Use B to look for them. - The letter "A" in the diff-filter string does not match anything itself, but causes the entire diff that contains selected patches to be output (this behaviour is similar to that of --pickaxe-all for the -S option). For example, $ git-rev-list HEAD | git-diff-tree --stdin -s -v -B -C --diff-filter=BCR shows a list of commits that have complete rewrite, copy, or rename. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] Fix rename/copy when dealing with temporarily broken pairs.Libravatar Junio C Hamano1-0/+1
When rename/copy uses a file that was broken by diffcore-break as the source, and the broken filepair gets merged back later, the output was mislabeled as a rename. In this case, the source file ends up staying in the output, so we should label it as a copy instead. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] Re-Fix SIGSEGV on unmerged files in git-diff-files -pLibravatar Junio C Hamano1-0/+1
When an unmerged path was fed via diff_unmerged() into diffcore, it eventually called run_diff() with "one" and "two" parameters with NULL, but run_diff() was not written carefully enough to notice this situation. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-05diff 'rename' format change.Libravatar Linus Torvalds1-2/+2
Clearly even Junio felt git "rename" header lines should say "from/to" instead of "old/new", since he wrote the documentation that way. This way it also matches "copy". git-apply will accept both versions, at least for a while.
2005-06-05[PATCH] diff.c: -B argument passing fix.Libravatar Junio C Hamano1-2/+2
This fixes a bug that was preventing non-default parameter to -B option to be passed correctly; you could not give more than 50% break score. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-05[PATCH] diff.c: locate_size_cache() fix.Libravatar Junio C Hamano1-5/+6
This fixes two bugs. - declaration of auto variable "cmp" was preceeded by a statement, causing compilation error on real C compilers; noticed and patch given by Yoichi Yuasa. - the function's calling convention was overloading its size parameter to mean "largest possible value means do not add entry", which was a bad taste. Brought up during a discussion with Peter Baudis. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-03[PATCH] diff: Update -B heuristics.Libravatar Junio C Hamano1-2/+16
As Linus pointed out on the mailing list discussion, -B should break a files that has many inserts even if it still keeps enough of the original contents, so that the broken pieces can later be matched with other files by -M or -C. However, if such a broken pair does not get picked up by -M or -C, we would want to apply different criteria; namely, regardless of the amount of new material in the result, the determination of "rewrite" should be done by looking at the amount of original material still left in the result. If you still have the original 97 lines from a 100-line document, it does not matter if you add your own 13 lines to make a 110-line document, or if you add 903 lines to make a 1000-line document. It is not a rewrite but an in-place edit. On the other hand, if you did lose 97 lines from the original, it does not matter if you added 27 lines to make a 30-line document or if you added 997 lines to make a 1000-line document. You did a complete rewrite in either case. This patch introduces a post-processing phase that runs after diffcore-rename matches up broken pairs diffcore-break creates. The purpose of this post-processing is to pick up these broken pieces and merge them back into in-place modifications. For this, the score parameter -B option takes is changed into a pair of numbers, and it takes "-B99/80" format when fully spelled out. The first number is the minimum amount of "edit" (same definition as what diffcore-rename uses, which is "sum of deletion and insertion") that a modification needs to have to be broken, and the second number is the minimum amount of "delete" a surviving broken pair must have to avoid being merged back together. It can be abbreviated to "-B" to use default for both, "-B9" or "-B9/" to use 90% for "edit" but default (80%) for merge avoidance, or "-B/75" to use default (99%) "edit" and 75% for merge avoidance. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>