| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| |
| |
| |
| |
| | |
* ar/maint-mksnpath:
Fix potentially dangerous uses of mkpath and git_path
Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
Add mksnpath which allows you to specify the output buffer
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Replace them with mksnpath/git_snpath and a local buffer
for the resulting string.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\ \
| |/
| |
| |
| |
| | |
* maint:
test-lib: fix broken printf
git apply --directory broken for new files
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We carefully verify that the input to git-apply is sane,
including cross-checking that the filenames we see in "+++"
headers match what was provided on the command line of "diff
--git". When --directory is used, however, we ended up
comparing the unadorned name to one with the prepended root,
causing us to complain about a mismatch.
We simply need to prepend the root directory, if any, when
pulling the name out of the git header.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
* maint:
builtin-apply: fix typo leading to stack corruption
git-stash.sh: fix flawed fix of invalid ref handling (commit da65e7c1)
builtin-merge.c: allocate correct amount of memory
Makefile: do not set NEEDS_LIBICONV for Solaris 8
rebase -i: remove leftover debugging
rebase -i: proper prepare-commit-msg hook argument when squashing
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This typo led to stack corruption for lines with whitespace fixes
and length > 1024.
Signed-off-by: Imre Deak <imre.deak@gmail.com>
Looks-good-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| | |
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| | |
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* bc/master-diff-hunk-header-fix:
Clarify commit error message for unmerged files
Use strchrnul() instead of strchr() plus manual workaround
Use remove_path from dir.c instead of own implementation
Add remove_path: a function to remove as much as possible of a path
git-submodule: Fix "Unable to checkout" for the initial 'update'
Clarify how the user can satisfy stash's 'dirty state' check.
t4018-diff-funcname: test syntax of builtin xfuncname patterns
t4018-diff-funcname: test syntax of builtin xfuncname patterns
make "git remote" report multiple URLs
diff hunk pattern: fix misconverted "\{" tex macro introducers
diff: fix "multiple regexp" semantics to find hunk header comment
diff: use extended regexp to find hunk headers
diff: use extended regexp to find hunk headers
diff.*.xfuncname which uses "extended" regex's for hunk header selection
diff.c: associate a flag with each pattern and use it for compiling regex
diff.c: return pattern entry pointer rather than just the hunk header pattern
Conflicts:
builtin-merge-recursive.c
t/t7201-co.sh
xdiff-interface.h
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Besides, it fixes a memleak (builtin-rm.c) and accidental change of
the input const argument (builtin-merge-recursive.c).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows --include=pathspec, similar to --exclude=pathspec.
The rule when one or both of these are used is that the include/exclude
patterns are examined in the order they are given on the command line, and
the first match determines if a patch to each path is used or not. Hence:
$ git apply --include='specific.h' --exclude='*.h' <diff
would apply the patch to specific.h header file, but all other patches in
the input file to other header files are ignored. A patch to a path that
does not match any include/exclude pattern is used by default if there is
no include pattern on the command line, and ignored if there is any
include pattern.
This originally came from Joe Perches, but both the design of the
semantics and the implementation have been redone complately.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* ho/dashless:
tests: use "git xyzzy" form (t7200 - t9001)
tests: use "git xyzzy" form (t7000 - t7199)
tests: use "git xyzzy" form (t3600 - t6999)
tests: use "git xyzzy" form (t0000 - t3599)
'git foo' program identifies itself without dash in die() messages
Start conforming code to "git subcmd" style
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a mechanical conversion of all '*.c' files with:
s/((?:die|error|warning)\("git)-(\S+:)/$1 $2/;
The result was manually inspected and no false positive was found.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
User notifications are presented as 'git cmd', and code comments
are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even after a handfle attempts, match_beginning logic still has corner
cases:
1bf1a85 (apply: treat EOF as proper context., 2006-05-23)
65aadb9 (apply: force matching at the beginning., 2006-05-24)
4be6096 (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17)
ee5a317 (Fix "git apply" to correctly enforce "match ..., 2008-04-06)
This is a tricky piece of code.
We still incorrectly enforce "match_beginning" for -U0 matches.
I noticed this while trying out an example sequence from Clemens Buchacher:
$ echo a >victim
$ git add victim
$ echo b >>victim
$ git diff -U0 >patch
$ cat patch
diff --git i/victim w/victim
index 7898192..422c2b7 100644
--- i/victim
+++ w/victim
@@ -1,0 +2 @@ a
+b
$ git apply --cached --unidiff-zero <patch
$ git show :victim
b
a
The change inserts a new line before the second line, but we insist it to
be applied at the beginning. As the result, the code refuses to apply it
at the original offset, and we end up adding the line at the beginning.
Updates to the test script are by Clemens Buchacher.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form. So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.
This patch makes git commands show the dash-less version.
For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught "git-apply" to
grok a (non-git) patch that is a concatenation of separate patches that
touch the same file number of times, by recording the postimage of patch
application of previous round and using it as the preimage for later
rounds.
This "incremental" mode of patch application fundamentally contradicts
with the way git rename/copy patches are designed. When a git patch talks
about a file A getting modified, and a new file B created out of A, like
this:
diff --git a/A b/A
--- a/A
+++ b/A
... change text here ...
diff --git a/A b/B
copy from A
copy to B
--- a/A
+++ b/B
... change text here ...
the second change to produce B does not depend on what is done to A with
the first change in any way. This is explicitly done so for reviewability
of individual patches.
With this commit, we do not look at 'fn_table' that records the postimage
of previous round when applying a patch to produce a new file out of an
existing file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\
| |
| |
| |
| |
| |
| | |
* js/apply-root:
git-apply --directory: make --root more similar to GNU diff
apply --root: thinkofix.
Teach "git apply" to prepend a prefix with "--root=<root>"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Applying a patch in the directory that is different from what the patch
records is done with --directory option in GNU diff. The --root option we
introduced previously does the same, and we can call it the same way to
give users more familiar feel.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The end of a string is string[length-1], not string[length+1].
I pointed it out during the review, but I forgot about it when applying the
patch. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With "git apply --root=<root>", all file names in the patch are prepended
with <root>. If a "-p" value was given, the paths are stripped _before_
prepending <root>.
Wished for by HPA.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a patch modifies the last line of a file that previously had no
terminating '\n', it looks like
-old text
\ No newline at end of file
+new text
Hence, a '\' line does not signal the end of the hunk. This modifies
'git apply --recount' to take this into account.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\ \
| | |
| | |
| | |
| | | |
* js/apply-recount:
Allow git-apply to recount the lines in a hunk (AKA recountdiff)
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sometimes, the easiest way to fix up a patch is to edit it directly, even
adding or deleting lines. Now, many people are not as divine as certain
benevolent dictators as to update the hunk headers correctly at the first
try.
So teach the tool to do it for us.
[jc: with tests]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When working with a lot of people who backport patches all day long, every
once in a while I get a patch that modifies the same file more than once
inside the same patch. git-apply either fails if the second change relies
on the first change or silently drops the first change if the second change
is independent.
The silent part is the scary scenario for us. Also this behaviour is
different from the patch-utils.
I have modified git-apply to create a table of the filenames of files it
modifies such that if a later patch chunk modifies a file in the table it
will buffer the previously changed file instead of reading the original file
from disk.
Logic has been put in to handle creations/deletions/renames/copies. All the
relevant tests of git-apply succeed.
A new test has been added to cover the cases I addressed.
The fix is relatively straight-forward.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* js/config-cb:
Provide git_config with a callback-data parameter
Conflicts:
builtin-add.c
builtin-cat-file.c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we see no context nor deleted line in the patch, we used to declare
that the patch creates a new file. But some people create an empty file
and then apply a patch to it. Similarly, a patch that delete everything
is not a deletion patch either.
This commit corrects these two issues. Together with the previous commit,
it allows a diff between an empty file and a line-ful file to be treated
as both creation patch and "add stuff to an existing empty file",
depending on the context. A new test t4126 demonstrates the fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A patch from a foreign SCM (or plain "diff" output) often have both
preimage and postimage filename on ---/+++ lines even for a patch that
creates a new file. However, when there is a filename for preimage, we
used to insist the file to exist (either in the work tree and/or in the
index). When we cannot be sure by parsing the patch that it is not a
creation patch, we shouldn't complain when if there is no such a file.
This commit fixes the logic.
Refactor the code that validates the preimage file into a separate
function while we are at it, as it is getting rather big.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |/
|
|
| |
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* maint:
git-bisect: make "start", "good" and "skip" succeed or fail atomically
git-am: cope better with an empty Subject: line
Ignore leading empty lines while summarizing merges
bisect: squelch "fatal: ref HEAD not a symref" misleading message
builtin-apply: Show a more descriptive error on failure when opening a patch
Clarify documentation of git-cvsserver, particularly in relation to git-shell
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* maint-1.5.4:
git-bisect: make "start", "good" and "skip" succeed or fail atomically
git-am: cope better with an empty Subject: line
Ignore leading empty lines while summarizing merges
bisect: squelch "fatal: ref HEAD not a symref" misleading message
builtin-apply: Show a more descriptive error on failure when opening a patch
Clarify documentation of git-cvsserver, particularly in relation to git-shell
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a patch can't be opened (it doesn't exist, there are permission
problems, etc.) we get the usage text, which is not a proper indication of
failure.
Signed-off-by: Alberto Bertogli <albertito@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |/ /
| |
| |
| |
| | |
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\ \
| |/
| |
| |
| | |
* jc/maint-apply-match-beginning:
Fix "git apply" to correctly enforce "match at the beginning"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An earlier commit 4be6096 (apply --unidiff-zero: loosen sanity checks for
--unidiff=0 patches, 2006-09-17) made match_beginning and match_end
computed incorrectly. If a hunk inserts at the beginning, old position
recorded at the hunk is line 0, and if a hunk changes at the beginning, it
is line 1. The new test added to t4104 exposes that the old code did not
insist on matching at the beginning for a patch to add a line to an empty
file.
An even older 65aadb9 (apply: force matching at the beginning.,
2006-05-24) was equally wrong in that it tried to take hints from the
number of leading context lines, to decide if the hunk must match at the
beginning, but we can just look at the line number in the hunk to decide.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
setup_git_directory_gently() only modified the value of its *nongit_ok
argument if we were not in a git repository. Now it will always set it
to 0 when we are inside a repository.
Also remove now unnecessary initializations in the callers of this
function.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* jc/apply-whitespace:
ws_fix_copy(): move the whitespace fixing function to ws.c
apply: do not barf on patch with too large an offset
core.whitespace: cr-at-eol
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
builtin-apply.c: pass ws_rule down to match_fragment()
builtin-apply.c: move copy_wsfix() function a bit higher.
builtin-apply.c: do not feed copy_wsfix() leading '+'
builtin-apply.c: simplify calling site to apply_line()
builtin-apply.c: clean-up apply_one_fragment()
builtin-apply.c: mark common context lines in lineinfo structure.
builtin-apply.c: optimize match_beginning/end processing a bit.
builtin-apply.c: make it more line oriented
builtin-apply.c: push match-beginning/end logic down
builtin-apply.c: restructure "offset" matching
builtin-apply.c: refactor small part that matches context
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is used by git-apply but we can use it elsewhere by slightly
generalizing it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously a patch that records too large a line number caused the
offset matching code in git-apply to overstep its internal buffer.
Noticed by Johannes Schindelin.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This new error mode allows a line to have a carriage return at the
end of the line when checking and fixing trailing whitespace errors.
Some people like to keep CRLF line ending recorded in the repository,
and still want to take advantage of the automated trailing whitespace
stripping. We still show ^M in the diff output piped to "less" to
remind them that they do have the CR at the end, but these carriage
return characters at the end are no longer flagged as errors.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When you have more than one patch series, an earlier one of which
tries to introduce whitespace breakages and a later one of which
has such a new line in its context, "git-apply --whitespace=fix"
will apply and fix the whitespace breakages in the earlier one,
making the resulting file not to match the context of the later
patch.
A short demonstration is in the new test, t4125.
For example, suppose the first patch is:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -20,3 +20,3 @@
Hello world.$
-How Are you$
-Today?$
+How are you $
+today? $
to fix broken case in the string, but it introduces unwanted
trailing whitespaces to the result (pretend you are looking at
"cat -e" output of the patch --- '$' signs are not in the patch
but are shown to make the EOL stand out). And the second patch
is to change the wording of the greeting further:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings $
-Hello world.$
+Hello, everybody. $
How are you $
-today? $
+these days? $
If you apply the first one with --whitespace=fix, you will get
this as the result:
Hello world.$
How are you$
today?$
and this does not match the preimage of the second patch, which
demands extra whitespace after "How are you" and "today?".
This series is about teaching "git apply --whitespace=fix" to
cope with this situation better. If the patch does not apply,
it rewrites the second patch like this and retries:
diff a/hello.txt b/hello.txt
--- a/hello.txt
+++ b/hello.txt
@@ -18,5 +18,5 @@
Greetings$
-Hello world.$
+Hello, everybody.$
How are you$
-today?$
+these days?$
This is done by rewriting the preimage lines in the hunk
(i.e. the lines that begin with ' ' or '-'), using the same
whitespace fixing rules as it is using to apply the patches, so
that it can notice what it did to the previous ones in the
series.
A careful reader may notice that the first patch in the example
did not touch the "Greetings" line, so the trailing whitespace
that is in the original preimage of the second patch is not from
the series. Is rewriting this context line a problem?
If you think about it, you will realize that the reason for the
difference is because the submitter's tree was based on an
earlier version of the file that had whitespaces wrong on that
"Greetings" line, and the change that introduced the "Greetings"
line was added independently of this two-patch series to our
tree already with an earlier "git apply --whitespace=fix".
So it may appear this logic is rewriting too much, it is not
so. It is just rewriting what we would have rewritten in the
past.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is necessary to allow match_fragment() to attempt a match
with a preimage that is based on a version before whitespace
errors were fixed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
I'll be calling this from match_fragment() in later rounds.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The "patch" parameter used to include leading '+' of an added
line in the patch, and the array was treated as 1-based. Make
it accept the contents of the line alone and simplify the code.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
