aboutsummaryrefslogtreecommitdiff
path: root/diff.c
Commit message (Collapse)AuthorAge
* Merge branch 'jc/checkdiff'Junio C Hamano2008-07-01
|\ | | | | | | | | | | | | | | | | | | | | * jc/checkdiff: Fix t4017-diff-retval for white-space from wc Update sample pre-commit hook to use "diff --check" diff --check: detect leftover conflict markers Teach "diff --check" about new blank lines at end checkdiff: pass diff_options to the callback check_and_emit_line(): rename and refactor diff --check: explain why we do not care whether old side is binary
| * diff --check: detect leftover conflict markersJunio C Hamano2008-06-26
| | | | | | | | | | | | | | | | | | | | This teaches "diff --check" to detect and complain if the change adds lines that look like leftover conflict markers. We should be able to remove the old Perl script used in the sample pre-commit hook and modernize the script with this facility. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Teach "diff --check" about new blank lines at endJunio C Hamano2008-06-26
| | | | | | | | | | | | | | When a patch adds new blank lines at the end, "git apply --whitespace" warns. This teaches "diff --check" to do the same. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * checkdiff: pass diff_options to the callbackJunio C Hamano2008-06-26
| | | | | | | | | | | | This way, we could later use more information from the diff_options. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * check_and_emit_line(): rename and refactorJunio C Hamano2008-06-26
| | | | | | | | | | | | | | | | | | The function name was too bland and not explicit enough as to what it is checking. Split it into two, and call the one that checks if there is a whitespace breakage "ws_check()", and call the other one that checks and emits the line after color coding "ws_check_emit()". Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * diff --check: explain why we do not care whether old side is binaryJunio C Hamano2008-06-26
| | | | | | | | | | | | | | | | | | All other codepaths refrain from running textual diff when either the old or the new side is binary, but this function only checks the new side. I was almost going to change it to check both, but that would be a bad change. Explain why to prevent future mistakes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | show_stats(): fix stats width calculationOlivier Marin2008-06-28
|/ | | | | | | | | | | Before this patch, name_width becomes negative or null for width values less than 15 and name_width values greater than 25 (default: 50). This leads to output random data. This patch checks for minimal width and name_width values. Signed-off-by: Olivier Marin <dkr@freesurf.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2008-06-26
|\ | | | | | | | | | | | | | | * maint: GIT 1.5.5.5 GIT 1.5.4.6 git-shell: accept "git foo" form diff --check: do not discard error status upon seeing a good line
| * diff --check: do not discard error status upon seeing a good lineJunio C Hamano2008-06-26
| | | | | | | | | | | | | | | | "git diff --check" should return non-zero when there was any whitespace error but the code only paid attention to the error status of the last new line in the patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/test'Junio C Hamano2008-06-22
|\ \ | |/ |/| | | | | | | | | | | | | * jk/test: enable whitespace checking of test scripts avoid trailing whitespace in zero-change diffstat lines avoid whitespace on empty line in automatic usage message mask necessary whitespace policy violations in test scripts fix whitespace violations in test scripts
| * avoid trailing whitespace in zero-change diffstat linesJeff King2008-06-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases, we produce a diffstat line even though no lines have changed (e.g., because of an exact rename). In this case, there is no +/- "graph" after the number of changed lines. However, we output the space separator unconditionally, meaning that these lines contained a trailing space character. This isn't a huge problem, but in cleaning up the output we are able to eliminate some trailing whitespace from a test vector. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'maint'Junio C Hamano2008-06-16
|\ \ | | | | | | | | | | | | * maint: diff.c: fix emit_line() again not to add extra line
| * | diff.c: fix emit_line() again not to add extra lineJunio C Hamano2008-06-16
| | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'maint'Junio C Hamano2008-06-16
|\ \ \ | |/ / | | / | |/ |/| * maint: diff: reset color before printing newline
| * diff: reset color before printing newlineSZEDER Gábor2008-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It worked that way since commit 50f575fc (Tweak diff colors, 2006-06-22), but commit c1795bb0 (Unify whitespace checking, 2007-12-13) changed it. This patch restores the old behaviour. Besides Linus' arguments in the log message of 50f575fc, resetting color before printing newline is also important to keep 'git add --patch' happy. If the last line(s) of a file are removed, then that hunk will end with a colored line. However, if the newline comes before the color reset, then the diff output will have an additional line at the end containing only the reset sequence. This causes trouble in git-add--interactive.perl's parse_diff function, because @colored will have one more element than @diff, and that last element will contain the color reset. The elements of these arrays will then be copied to @hunk, but only as many as the number of elements in @diff. As a result the last color reset is lost and all subsequent terminal output will be printed in color. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/config-cb'v1.5.6-rc0Junio C Hamano2008-05-25
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | * js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
| * | Provide git_config with a callback-data parameterJohannes Schindelin2008-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | diff options: Introduce --ignore-submodulesJohannes Schindelin2008-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new option --ignore-submodules can now be used to ignore changes in submodules. Why? Sometimes it is not interesting when a submodule changed. For example, when reordering some commits in the superproject, a dirty submodule is usually totally uninteresting. So we will use this option in git-rebase to test for a dirty working tree. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/renamelimit' (early part)Junio C Hamano2008-05-14
|\ \ \ | |/ / |/| | | | | | | | | | | | | | * 'jk/renamelimit' (early part): diff: make "too many files" rename warning optional bump rename limit defaults add merge.renamelimit config option
| * | bump rename limit defaultsJeff King2008-05-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current rename limit default of 100 was arbitrarily chosen. Testing[1] has shown that on modern hardware, a limit of 200 adds about a second of computation time, and a limit of 500 adds about 5 seconds of computation time. This patch bumps the default limit to 200 for viewing diffs, and to 500 for performing a merge. The limit for generating git-status templates is set independently; we bump it up to 200 here, as well, to match the diff limit. [1]: See <20080211113516.GB6344@coredump.intra.peff.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Remove dead code: show_log() sep argument and diff_options.msg_sepAdam Simpkins2008-05-03
|/ / | | | | | | | | | | | | | | These variables were made unnecessary by commit 3969cf7db1a13a78f3b7a36d8c1084bbe0a53459. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | diff: make --dirstat binary-file safeJunio C Hamano2008-04-09
|/ | | | | | | | Instead of counting added and removed lines (and mixing the byte size reported for binary files in the result), summarize the extent of damage the same way as we count similarity for rename detection. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Write diff output to a file in struct diff_optionsDaniel Barkalow2008-03-14
| | | | | Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* diff: make sure work tree side is shown as 0{40} when differentJunio C Hamano2008-03-02
| | | | | | | | | | | | | | | Ping Yin noticed that "git diff-index --raw" shows 0{40} when work tree has submodule difference, but "git diff --raw" didn't correctly do so. There was a mistake in the diffcore_skip_stat_unmatch() that was meant to clean up the stat-only difference for running diff between the index and work tree and diff between the tree and the work tree, to cause it re-read from the submodule repository HEAD. When ce_stat_match() says work tree is different, we should always say 0{40} on the work tree side. This patch fixes the issue, and adds tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Clean up find_unique_abbrev() callersJunio C Hamano2008-03-01
| | | | | | | | | | | | | | | Now find_unique_abbrev() never returns NULL, there is no need for callers to prepare for seeing NULL and fall back to giving the full 40-hexdigits. While we are at it, drop "..." in the "git reset" output that reports the location of the new HEAD, between the abbreviated commit object name and the one line commit summary. Because we are always showing the HEAD (which cannot be missing!), we never had a case where we show the full 40 hexdigits that is not followed by three dots, and these three dots were stealing 3 columns from the precious horizontal screen real estate out of 80 that can better be used for the one line commit summary. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jm/free'Junio C Hamano2008-02-27
|\ | | | | | | | | | | | | | | | | * jm/free: Avoid unnecessary "if-before-free" tests. Conflicts: builtin-branch.c
| * Avoid unnecessary "if-before-free" tests.Jim Meyering2008-02-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change removes all obvious useless if-before-free tests. E.g., it replaces code like this: if (some_expression) free (some_expression); with the now-equivalent: free (some_expression); It is equivalent not just because POSIX has required free(NULL) to work for a long time, but simply because it has worked for so long that no reasonable porting target fails the test. Here's some evidence from nearly 1.5 years ago: http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html FYI, the change below was prepared by running the following: git ls-files -z | xargs -0 \ perl -0x3b -pi -e \ 's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s' Note however, that it doesn't handle brace-enclosed blocks like "if (x) { free (x); }". But that's ok, since there were none like that in git sources. Beware: if you do use the above snippet, note that it can produce syntactically invalid C code. That happens when the affected "if"-statement has a matching "else". E.g., it would transform this if (x) free (x); else foo (); into this: free (x); else foo (); There were none of those here, either. If you're interested in automating detection of the useless tests, you might like the useless-if-before-free script in gnulib: [it *does* detect brace-enclosed free statements, and has a --name=S option to make it detect free-like functions with different names] http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free Addendum: Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jc/diff-relative'Junio C Hamano2008-02-27
|\ \ | | | | | | | | | | | | | | | * jc/diff-relative: diff --relative: help working in a bare repository diff --relative: output paths as relative to the current subdirectory
| * | diff --relative: help working in a bare repositoryJunio C Hamano2008-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the --relative option to say which subdirectory to pretend to be in, so that in a bare repository, you can say: $ git log --relative=drivers/ v2.6.20..v2.6.22 -- drivers/scsi/ Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | diff --relative: output paths as relative to the current subdirectoryJunio C Hamano2008-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds --relative option to the diff family. When you start from a subdirectory: $ git diff --relative shows only the diff that is inside your current subdirectory, and without $prefix part. People who usually live in subdirectories may like it. There are a few things I should also mention about the change: - This works not just with diff but also works with the log family of commands, but the history pruning is not affected. In other words, if you go to a subdirectory, you can say: $ git log --relative -p but it will show the log message even for commits that do not touch the current directory. You can limit it by giving pathspec yourself: $ git log --relative -p . This originally was not a conscious design choice, but we have a way to affect diff pathspec and pruning pathspec independently. IOW "git log --full-diff -p ." tells it to prune history to commits that affect the current subdirectory but show the changes with full context. I think it makes more sense to leave pruning independent from --relative than the obvious alternative of always pruning with the current subdirectory, which would break the symmetry. - Because this works also with the log family, you could format-patch a single change, limiting the effect to your subdirectory, like so: $ cd gitk-git $ git format-patch -1 --relative 911f1eb But because that is a special purpose usage, this option will never become the default, with or without repository or user preference configuration. The risk of producing a partial patch and sending it out by mistake is too great if we did so. - This is inherently incompatible with --no-index, which is a bolted-on hack that does not have much to do with git itself. I didn't bother checking and erroring out on the combined use of the options, but probably I should. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'maint'Junio C Hamano2008-02-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Documentation/git-am.txt: Pass -r in the example invocation of rm -f .dotest timezone_names[]: fixed the tz offset for New Zealand. filter-branch documentation: non-zero exit status in command abort the filter rev-parse: fix potential bus error with --parseopt option spec handling Use a single implementation and API for copy_file() Documentation/git-filter-branch: add a new msg-filter example Correct fast-export file mode strings to match fast-import standard
| * | | Use a single implementation and API for copy_file()Daniel Barkalow2008-02-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally by Kristian Hï¿œgsberg; I fixed the conversion of rerere, which had a different API. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'lt/dirstat'Junio C Hamano2008-02-24
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | * lt/dirstat: diff --dirstat: saner handling of binary and unmerged files Add "--dirstat" for some directory statistics
| * | | diff --dirstat: saner handling of binary and unmerged filesJunio C Hamano2008-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do not account binary nor unmerged files when --shortstat is asked for (or the summary stat at the end of --stat). The new option --dirstat should work the same way as it is about summarizing the changes of multiple files by adding them up. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Add "--dirstat" for some directory statisticsLinus Torvalds2008-02-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new form of overview diffstat output, doing something that I have occasionally ended up doing manually (and badly, because it's actually pretty nasty to do), and that I think is very useful for an project like the kernel that has a fairly deep and well-separated directory structure with semantic meaning. What I mean by that is that it's often interesting to see exactly which sub-directories are impacted by a patch, and to what degree - even if you don't perhaps care so much about the individual files themselves. What makes the concept more interesting is that the "impact" is often hierarchical: in the kernel, for example, something could either have a very localized impact to "fs/ext3/" and then it's interesting to see that such a patch changes mostly that subdirectory, but you could have another patch that changes some generic VFS-layer issue which affects _many_ subdirectories that are all under "fs/", but none - or perhaps just a couple of them - of the individual filesystems are interesting in themselves. So what commonly happens is that you may have big changes in a specific sub-subdirectory, but still also significant separate changes to the subdirectory leading up to that - maybe you have significant VFS-level changes, but *also* changes under that VFS layer in the NFS-specific directories, for example. In that case, you do want the low-level parts that are significant to show up, but then the insignificant ones should show up as under the more generic top-level directory. This patch shows all of that with "--dirstat". The output can be either something simple like commit 81772fe... Author: Thomas Gleixner <tglx@linutronix.de> Date: Sun Feb 10 23:57:36 2008 +0100 x86: remove over noisy debug printk pageattr-test.c contains a noisy debug printk that people reported. The condition under which it prints (randomly tapping into a mem_map[] hole and not being able to c_p_a() there) is valid behavior and not interesting to report. Remove it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 100.0% arch/x86/mm/ or something much more complex like commit e231c2e... Author: David Howells <dhowells@redhat.com> Date: Thu Feb 7 00:15:26 2008 -0800 Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p) 20.5% crypto/ 7.6% fs/afs/ 7.6% fs/fuse/ 7.6% fs/gfs2/ 5.1% fs/jffs2/ 5.1% fs/nfs/ 5.1% fs/nfsd/ 7.6% fs/reiserfs/ 15.3% fs/ 7.6% net/rxrpc/ 10.2% security/keys/ where that latter example is an example of significant work in some individual fs/*/ subdirectories (like the patches to reiserfs accounting for 7.6% of the whole), but then discounting those individual filesystems, there's also 15.3% other "random" things that weren't worth reporting on their oen left over under fs/ in general (either in that directory itself, or in subdirectories of fs/ that didn't have enough changes to be reported individually). I'd like to stress that the "15.3% fs/" mentioned above is the stuff that is under fs/ but that was _not_ significant enough to report on its own. So the above does _not_ mean that 15.3% of the work was under fs/ per se, because that 15.3% does *not* include the already-reported 7.6% of afs, 7.6% of fuse etc. If you want to enable "cumulative" directory statistics, you can use the "--cumulative" flag, which adds up percentages recursively even when they have been already reported for a sub-directory. That cumulative output is disabled if *all* of the changes in one subdirectory come from a deeper subdirectory, to avoid repeating subdirectories all the way to the root. For an example of the cumulative reporting, the above commit becomes commit e231c2e... Author: David Howells <dhowells@redhat.com> Date: Thu Feb 7 00:15:26 2008 -0800 Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p) 20.5% crypto/ 7.6% fs/afs/ 7.6% fs/fuse/ 7.6% fs/gfs2/ 5.1% fs/jffs2/ 5.1% fs/nfs/ 5.1% fs/nfsd/ 7.6% fs/reiserfs/ 61.5% fs/ 7.6% net/rxrpc/ 10.2% security/keys/ in which the commit percentages now obviously add up to much more than 100%: now the changes that were already reported for the sub-directories under fs/ are then cumulatively included in the whole percentage of fs/ (ie now shows 61.5% as opposed to the 15.3% without the cumulative reporting). The default reporting limit has been arbitrarily set at 3%, which seems to be a pretty good cut-off, but you can specify the cut-off manually by giving it as an option parameter (eg "--dirstat=5" makes the cut-off be at 5% instead) NOTE! The percentages are purely about the total lines added and removed, not anything smarter (or dumber) than that. Also note that you should not generally expect things to add up to 100%: not only does it round down, we don't report leftover scraps (they add up to the top-level change count, but we don't even bother reporting that, it only reports subdirectories). Quite frankly, as a top-level manager this is really convenient for me, but it's going to be very boring for git itself since there are few subdirectories. Also, don't expect things to make tons of sense if you combine this with "-M" and there are cross-directory renames etc. But even for git itself, you can get some fun statistics. Try out git log --dirstat and see the occasional mentions of things like Documentation/, git-gui/, gitweb/ and gitk-git/. Or try out something like git diff --dirstat v1.5.0..v1.5.4 which does kind of git an overview that shows *something*. But in general, the output is more exciting for big projects with deeper structure, and doing a git diff --dirstat v2.6.24..v2.6.25-rc1 on the kernel is what I actually wrote this for! Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | diff: fix java funcname pattern for solarisJeff King2008-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Solaris regex library doesn't like having the '$' anchor inside capture parentheses. It rejects the match, causing t4018 to fail. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Add color.ui variable which globally enables colorization if setMatthias Kestenholz2008-02-18
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Matthias Kestenholz <mk@spinlock.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'sp/safecrlf'Junio C Hamano2008-02-16
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | * sp/safecrlf: safecrlf: Add mechanism to warn about irreversible crlf conversions
| * | | | safecrlf: Add mechanism to warn about irreversible crlf conversionsSteffen Prohaska2008-02-06
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CRLF conversion bears a slight chance of corrupting data. autocrlf=true will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data. If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes. Right after committing you still have the original file in your work tree and this file is not yet corrupted. You can explicitly tell git that this file is binary and git will handle the file appropriately. Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs corrupts data. This patch adds a mechanism that can either warn the user about an irreversible conversion or can even refuse to convert. The mechanism is controlled by the variable core.safecrlf, with the following values: - false: disable safecrlf mechanism - warn: warn about irreversible conversions - true: refuse irreversible conversions The default is to warn. Users are only affected by this default if core.autocrlf is set. But the current default of git is to leave core.autocrlf unset, so users will not see warnings unless they deliberately chose to activate the autocrlf mechanism. The safecrlf mechanism's details depend on the git command. The general principles when safecrlf is active (not false) are: - we warn/error out if files in the work tree can modified in an irreversible way without giving the user a chance to backup the original file. - for read-only operations that do not modify files in the work tree we do not not print annoying warnings. There are exceptions. Even though... - "git add" itself does not touch the files in the work tree, the next checkout would, so the safety triggers; - "git apply" to update a text file with a patch does touch the files in the work tree, but the operation is about text files and CRLF conversion is about fixing the line ending inconsistencies, so the safety does not trigger; - "git diff" itself does not touch the files in the work tree, it is often run to inspect the changes you intend to next "git add". To catch potential problems early, safety triggers. The concept of a safety check was originally proposed in a similar way by Linus Torvalds. Thanks to Dimitry Potapov for insisting on getting the naked LF/autocrlf=true case right. Signed-off-by: Steffen Prohaska <prohaska@zib.de>
* | | | Merge branch 'maint'Junio C Hamano2008-02-16
|\ \ \ \ | |_|/ / |/| | / | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: commit: discard index after setting up partial commit filter-branch: handle filenames that need quoting diff: Fix miscounting of --check output hg-to-git: fix parent analysis mailinfo: feed only one line to handle_filter() for QP input diff.c: add "const" qualifier to "char *cmd" member of "struct ll_diff_driver" Add "const" qualifier to "char *excludes_file". Add "const" qualifier to "char *editor_program". Add "const" qualifier to "char *pager_program". config: add 'git_config_string' to refactor string config variables. diff.c: remove useless check for value != NULL fast-import: check return value from unpack_entry() Validate nicknames of remote branches to prohibit confusing ones diff.c: replace a 'strdup' with 'xstrdup'. diff.c: fixup garding of config parser from value=NULL
| * | diff: Fix miscounting of --check outputJunio C Hamano2008-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | c1795bb (Unify whitespace checking) incorrectly made the checking function return without incrementing the line numbers when there is no whitespace problem is found on a '+' line. This resurrects the earlier behaviour. Noticed and reported by Jay Soffian. The test script was stolen from Jay's independent fix. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | diff.c: add "const" qualifier to "char *cmd" member of "struct ll_diff_driver"Christian Couder2008-02-15
| | | | | | | | | | | | | | | | | | | | | Also use "git_config_string" to simplify code where "cmd" is set. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | diff.c: remove useless check for value != NULLChristian Couder2008-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is not necessary to check if value != NULL before calling 'parse_lldiff_command' as there is already a check inside this function. By the way this patch also improves the existing check inside 'parse_lldiff_command' by using: return config_error_nonbool(var); instead of: return error("%s: lacks value", var); Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | diff.c: replace a 'strdup' with 'xstrdup'.Christian Couder2008-02-15
| | | | | | | | | | | | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | diff.c: fixup garding of config parser from value=NULLJunio C Hamano2008-02-15
| | | | | | | | | | | | | | | | | | | | | | | | Christian Couder noticed that there still were a handcrafted error() call that we should have converted to config_error_nonbool() where parse_lldiff_command() parses the configuration file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'lt/in-core-index'Junio C Hamano2008-02-11
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * lt/in-core-index: lazy index hashing Create pathname-based hash-table lookup into index read-cache.c: introduce is_racy_timestamp() helper read-cache.c: fix a couple more CE_REMOVE conversion Also use unpack_trees() in do_diff_cache() Make run_diff_index() use unpack_trees(), not read_tree() Avoid running lstat(2) on the same cache entry. index: be careful when handling long names Make on-disk index representation separate from in-core one
| * | Avoid running lstat(2) on the same cache entry.Junio C Hamano2008-01-21
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aside from the lstat(2) done for work tree files, there are quite many lstat(2) calls in refname dwimming codepath. This patch is not about reducing them. * It adds a new ce_flag, CE_UPTODATE, that is meant to mark the cache entries that record a regular file blob that is up to date in the work tree. If somebody later walks the index and wants to see if the work tree has changes, they do not have to be checked with lstat(2) again. * fill_stat_cache_info() marks the cache entry it just added with CE_UPTODATE. This has the effect of marking the paths we write out of the index and lstat(2) immediately as "no need to lstat -- we know it is up-to-date", from quite a lot fo callers: - git-apply --index - git-update-index - git-checkout-index - git-add (uses add_file_to_index()) - git-commit (ditto) - git-mv (ditto) * refresh_cache_ent() also marks the cache entry that are clean with CE_UPTODATE. * write_index is changed not to write CE_UPTODATE out to the index file, because CE_UPTODATE is meant to be transient only in core. For the same reason, CE_UPDATE is not written to prevent an accident from happening. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | diff.c: guard config parser from value=NULLJunio C Hamano2008-02-11
|/ | | | | | | diff.external, diff.*.command, diff.color.*, color.diff.* and diff.*.funcname configuration variables expect a string value. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* color unchanged lines as "plain" in "diff --color-words"Jeff King2008-01-18
| | | | | | These were mistakenly being colored in "meta" color. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Correct spelling in diff.c commentBill Lear2008-01-16
| | | | | | | Correct a spelling mistake in a comment. Signed-off-by: Bill Lear <rael@zopyra.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-27 07:50:26 +0000