Jens Lehmann [Sat, 13 Mar 2010 22:00:27 +0000 (23:00 +0100)]
git status: ignoring untracked files must apply to submodules too
Since 1.7.0 submodules are considered dirty when they contain untracked
files. But when git status is called with the "-uno" option, the user
asked to ignore untracked files, so they must be ignored in submodules
too. To achieve this, the new flag DIFF_OPT_IGNORE_UNTRACKED_IN_SUBMODULES
is introduced.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 14 Mar 2010 05:31:42 +0000 (21:31 -0800)]
Merge branch 'maint'
* maint:
don't use default revision if a rev was specified
for_each_recent_reflog_ent(): use strbuf, fix offset handling
t/Makefile: remove test artifacts upon "make clean"
blame: fix indent of line numbers
Dave Olszewski [Sat, 13 Mar 2010 22:47:05 +0000 (14:47 -0800)]
don't use default revision if a rev was specified
If a revision is specified, it happens not to have any commits, don't
use the default revision. By doing so, surprising and undesired
behavior can happen, such as showing the reflog for HEAD when a branch
was specified.
[jc: squashed a test from René]
Signed-off-by: Dave Olszewski <cxreg@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
René Scharfe [Sat, 13 Mar 2010 17:37:50 +0000 (18:37 +0100)]
for_each_recent_reflog_ent(): use strbuf, fix offset handling
As Vladimir reported, "git log -g refs/stash" surprisingly showed the reflog
of HEAD if the message in the reflog file was too long. To fix this, convert
for_each_recent_reflog_ent() to use strbuf_getwholeline() instead of fgets(),
for safety and to avoid any size limits for reflog entries.
Also reverse the logic of the part of the function that only looks at file
tails. It used to close the file if fgets() succeeded. The following
fgets() call in the while loop was likely to fail in this case, too, so
passing an offset to for_each_recent_reflog_ent() never worked. Change it to
error out if strbuf_getwholeline() fails instead.
Reported-by: Vladimir Panteleev <vladimir@thecybershadow.net> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
René Scharfe [Sat, 13 Mar 2010 10:25:12 +0000 (11:25 +0100)]
blame: fix indent of line numbers
Correct the calculation of the number of digits for line counts of the
form 10^n-1 (9, 99, ...) in lineno_width(). This makes blame stop
printing an extra space before the line numbers of files with that many
total lines.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jens Lehmann [Fri, 12 Mar 2010 21:23:52 +0000 (22:23 +0100)]
git status: Fix false positive "new commits" output for dirty submodules
Testing if the output "new commits" should appear in the long format of
"git status" is done by comparing the hashes of the diffpair. This always
resulted in printing "new commits" for submodules that contained untracked
or modified content, even if they did not contain new commits. The reason
was that match_stat_with_submodule() did set the "changed" flag for dirty
submodules, resulting in two->sha1 being set to the null_sha1 at the call
sites, which indicates that new commits are present. This is changed so
that when no new commits are present, the same object names are in the
sha1 field for both sides of the filepair, and the working tree side will
have the "dirty_submodule" flag set when appropriate. For a submodule to
be seen as modified even when it just has a dirty work tree, some
conditions had to be extended to also check for the "dirty_submodule"
flag.
Unfortunately the test case that should have found this bug had been
changed incorrectly too. It is fixed and extended to test for other
combinations too.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jens Lehmann [Thu, 11 Mar 2010 21:50:25 +0000 (22:50 +0100)]
Refactor dirty submodule detection in diff-lib.c
Moving duplicated code into the new function match_stat_with_submodule().
Replacing the implicit activation of detailed checks for the dirtiness of
submodules when DIFF_FORMAT_PATCH was selected with explicitly setting
the recently added DIFF_OPT_DIRTY_SUBMODULES option in diff_setup_done().
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stephen Boyd [Sat, 27 Feb 2010 08:59:22 +0000 (00:59 -0800)]
notes: rework subcommands and parse options
Running 'git notes copy -h' is not very helfpul right now. It lists
the options for all the git notes subcommands and is rather confusing.
Fix this by splitting cmd_notes() into separate functions for each
subcommand (besides append and edit since they're very similar) and
only providing a usage message for the subcommand.
This has an added benefit of reducing the code complexity while making
it safer and easier to read. The downside is we get some code bloat
from similar setup and teardown needed for notes and options parsing.
We also get a bit stricter in options parsing by only allowing
the ref option to come before the subcommand.
Acked-by: Johan Herland <johan@herland.net> Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:37 +0000 (18:04 +0100)]
git-notes(1): add a section about the meaning of history
To the displaying code, the only interesting thing about a notes ref
is that it has a tree of the required format. However, notes actually
have a history since they are recorded as successive commits.
Make a note about the existence of this history in the manpage, but
keep some doors open if we want to change the details.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:36 +0000 (18:04 +0100)]
notes: track whether notes_trees were changed at all
Currently, the notes copying is a bit wasteful since it always creates
new trees, even if no notes were copied at all.
Teach add_note() and remove_note() to flag the affected notes tree as
changed ('dirty'). Then teach builtin/notes.c to use this knowledge
and avoid committing trees that weren't changed.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:35 +0000 (18:04 +0100)]
notes: add shorthand --ref to override GIT_NOTES_REF
Adds a shorthand option that overrides the GIT_NOTES_REF variable, and
hence determines the notes tree that will be manipulated. It also
DWIMs a refs/notes/ prefix.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:34 +0000 (18:04 +0100)]
commit --amend: copy notes to the new commit
Teaches 'git commit --amend' to copy notes. The catch is that this
must also be guarded by --no-post-rewrite, which we use to prevent
--amend from copying notes during a rebase -i 'edit'/'reword'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:32 +0000 (18:04 +0100)]
notes: implement helpers needed for note copying during rewrite
Implement helper functions to load the rewriting config, and to
actually copy the notes. Also document the config.
Secondly, also implement an undocumented --for-rewrite=<cmd> option to
'git notes copy' which is used like --stdin, but also puts the
configuration for <cmd> into effect. It will be needed to support the
copying in git-rebase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:31 +0000 (18:04 +0100)]
notes: implement 'git notes copy --stdin'
This implements a mass-copy command that takes a sequence of lines in
the format
<from-sha1> SP <to-sha1> [ SP <rest> ] LF
on stdin, and copies each <from-sha1>'s notes to the <to-sha1>. The
<rest> is ignored. The intent, of course, is that this can read the
same input that the 'post-rewrite' hook gets.
The copy_note() function is exposed for everyone's and in particular
the next commit's use.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:30 +0000 (18:04 +0100)]
rebase -i: invoke post-rewrite hook
Aside from the same issue that rebase also has (remembering the
original commit across a conflict resolution), rebase -i brings an
extra twist: We need to defer writing the rewritten list in the case
of {squash,fixup} because their rewritten result should be the last
commit in the squashed group.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:29 +0000 (18:04 +0100)]
rebase: invoke post-rewrite hook
We have to deal with two separate code paths: a normal rebase, which
actually goes through git-am; and rebase {-m|-s}.
The only small issue with both is that they need to remember the
original sha1 across a possible conflict resolution. rebase -m
already puts this information in $dotest/current, and we just
introduce a similar file for git-am.
Note that in git-am, the hook really only runs when coming from
git-rebase: the code path that sets the $dotest/original-commit file
is guarded by a test for $dotest/rebasing.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:28 +0000 (18:04 +0100)]
commit --amend: invoke post-rewrite hook
The rough structure of run_rewrite_hook() comes from
run_receive_hook() in receive-pack.
We introduce a --no-post-rewrite option and use it to avoid the hook
when called from git-rebase -i 'edit'. The next patch will add full
support in git-rebase, and we only want to invoke the hook once.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 12 Mar 2010 17:04:27 +0000 (18:04 +0100)]
Documentation: document post-rewrite hook
This defines the behaviour of the post-rewrite hook support, which
will be implemented in the following patches.
We deliberately do not document how often the hook will be invoked per
rewriting command, but the interface is designed to keep that at
"once". This would currently not matter too much, since both rebase
and filter-branch are shellscripts and spawn many processes anyway.
However, when a fast sequencer in C is implemented, it will be
beneficial to only have to run the hook once.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 10 Mar 2010 23:32:43 +0000 (15:32 -0800)]
Merge branch 'sd/init-template'
* sd/init-template:
wrap-for-bin: do not export an empty GIT_TEMPLATE_DIR
t/t0001-init.sh: add test for 'init with init.templatedir set'
init: having keywords without value is not a global error.
Add a "TEMPLATE DIRECTORY" section to git-init[1].
Add `init.templatedir` configuration variable.
Junio C Hamano [Wed, 10 Mar 2010 23:32:34 +0000 (15:32 -0800)]
Merge branch 'sh/am-keep-cr'
* sh/am-keep-cr:
git-am: Add tests for `--keep-cr`, `--no-keep-cr` and `am.keepcr`
git-am: Add am.keepcr and --no-keep-cr to override it
git-am: Add command line parameter `--keep-cr` passing it to git-mailsplit
documentation: 'git-mailsplit --keep-cr' is not hidden anymore
Junio C Hamano [Wed, 10 Mar 2010 23:31:34 +0000 (15:31 -0800)]
Makefile: update check-docs target
When we added bunch of git-remote-* helper backends, we should have
done this to squelch complaints that they do not have their own
manual pages. Also the entry for git-remote-helpers was not
properly marked as a non-command.
Jens Lehmann [Tue, 9 Mar 2010 14:55:32 +0000 (15:55 +0100)]
git submodule summary: Handle HEAD as argument when on an unborn branch
When calling "git submodule summary HEAD" on an unborn branch the output
was empty even when it shouldn't have been ("git submodule summary"
without the HEAD argument prints the expected output since commit
"submodule summary: do not fail before the first commit").
This also fixes "git status" to emit the "Submodule changes to be
committed" section on an unborn branch when used with the
status.submodulesummary config option.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 9 Mar 2010 08:22:54 +0000 (00:22 -0800)]
show --first-parent/-m: do not default to --cc
Given that "git show" always shows some diff and does not walk the history
by default, it is natural to expect "git show --first-parent" to show the
difference between the given commit and its first parent. It also would
be natural, given that "--cc" is the default, "git show -m" to show
pairwise difference from each of the parents.
We however always defaulted to --cc and there was no way to turn it off.
Junio C Hamano [Tue, 9 Mar 2010 07:27:25 +0000 (23:27 -0800)]
show -c: show patch text
Traditionally, "show" defaulted to "show --cc" (dense combined patch), but
asking for combined patch with "show -c" didn't turn the patch output
format on; the placement of this logic in setup_revisions() dates back to cd2bdc5 (Common option parsing for "git log --diff" and friends,
2006-04-14).
This unfortunately cannot be done as a trivial change of "if dense
combined is asked, default to patch format" done in setup_revisions() to
"if any combined is asked, default to patch format", as "diff-tree -c"
needs to default to raw, while "diff-tree --cc" needs to default to patch,
and they share the codepath. These command specific defaults are now
handled in the new "tweak" callback that can be customized by individual
command implementations.
Junio C Hamano [Tue, 9 Mar 2010 06:58:09 +0000 (22:58 -0800)]
revision: introduce setup_revision_opt
So far the last parameter to setup_revisions() was to specify the default
ref when the command line did not give any (typically "HEAD"). This changes
it to take a pointer to a structure so that we can add other information without
touching too many codepaths in later patches.
Stephen Boyd [Sun, 7 Mar 2010 22:46:48 +0000 (14:46 -0800)]
send-email: add --no-cc, --no-to, and --no-bcc
There's no way to override the sendemail.to, sendemail.cc, and
sendemail.bcc config settings. Add options allowing the user to tell
git to ignore the config settings and take whatever is on the command
line.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stephen Boyd [Sun, 7 Mar 2010 22:46:47 +0000 (14:46 -0800)]
format-patch: add --no-cc, --no-to, and --no-add-headers
These new options allow users to override their config settings for
format.cc, format.to and format.headers respectively. These options
only make git ignore the config settings and any previous command line
options, so you'll still have to add more command line options to add
extra headers. For example,
Stephen Boyd [Sun, 7 Mar 2010 22:46:46 +0000 (14:46 -0800)]
format-patch: use a string_list for headers
In the next patch we'll need to clear the header lists if the user
specifies --no-add-headers or --no-to or --no-cc. This actually cuts
down on the code a bit too.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jens Lehmann [Mon, 8 Mar 2010 12:53:19 +0000 (13:53 +0100)]
git status: Show detailed dirty status of submodules in long format
Since 1.7.0 there are three reasons a submodule is considered modified
against the work tree: It contains new commits, modified content or
untracked content. Lets show all reasons in the long format of git status,
so the user can better asses the nature of the modification. This change
does not affect the short and porcelain formats.
Two new members are added to "struct wt_status_change_data" to store the
information gathered by run_diff_files(). wt-status.c uses the new flag
DIFF_OPT_DIRTY_SUBMODULES to tell diff-lib.c it wants to get detailed
dirty information about submodules.
A hint line for submodules is printed in the dirty header when dirty
submodules are present.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 8 Mar 2010 08:36:02 +0000 (00:36 -0800)]
Merge branch 'gb/maint-submodule-env' into maint
* gb/maint-submodule-env:
is_submodule_modified(): clear environment properly
submodules: ensure clean environment when operating in a submodule
shell setup: clear_local_git_env() function
rev-parse: --local-env-vars option
Refactor list of of repo-local env vars
Junio C Hamano [Mon, 8 Mar 2010 08:36:00 +0000 (00:36 -0800)]
Merge branch 'jc/fetch-param' into maint
* jc/fetch-param:
fetch --all/--multiple: keep all the fetched branch information
builtin-fetch --all/--multi: propagate options correctly
t5521: fix and modernize
Junio C Hamano [Mon, 8 Mar 2010 08:36:00 +0000 (00:36 -0800)]
Merge branch 'ne/pack-local-doc' into maint
* ne/pack-local-doc:
pack-objects documentation: Fix --honor-pack-keep as well.
pack-objects documentation: reword "objects that appear in the standard input"
Documentation: pack-objects: Clarify --local's semantics.
Junio C Hamano [Mon, 8 Mar 2010 08:36:00 +0000 (00:36 -0800)]
Merge branch 'mm/mkstemps-mode-for-packfiles' into maint
* mm/mkstemps-mode-for-packfiles:
Use git_mkstemp_mode instead of plain mkstemp to create object files
git_mkstemps_mode: don't set errno to EINVAL on exit.
Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later.
git_mkstemp_mode, xmkstemp_mode: variants of gitmkstemps with mode argument.
Move gitmkstemps to path.c
Add a testcase for ACL with restrictive umask.
Mark Lodato [Sun, 7 Mar 2010 16:52:47 +0000 (11:52 -0500)]
grep: Colorize selected, context, and function lines
Colorize non-matching text of selected lines, context lines, and
function name lines. The default for all three is no color, but they
can be configured using color.grep.<slot>. The first two are similar
to the corresponding options in GNU grep, except that GNU grep applies
the color to the entire line, not just non-matching text.
Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark Lodato [Sun, 7 Mar 2010 16:52:46 +0000 (11:52 -0500)]
grep: Colorize filename, line number, and separator
Colorize the filename, line number, and separator in git grep output, as
GNU grep does. The colors are customizable through color.grep.<slot>.
The default is to only color the separator (in cyan), since this gives
the biggest legibility increase without overwhelming the user with
colors. GNU grep also defaults cyan for the separator, but defaults to
magenta for the filename and to green for the line number, as well.
There is one difference from GNU grep: When a binary file matches
without -a, GNU grep does not color the <file> in "Binary file <file>
matches", but we do.
Like GNU grep, if --null is given, the null separators are not colored.
For config.txt, use a a sub-list to describe the slots, rather than
a single paragraph with parentheses, since this is much more readable.
Remove the cast to int for `rm_eo - rm_so` since it is not necessary.
Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 7 Mar 2010 22:54:01 +0000 (14:54 -0800)]
Merge branch 'sp/maint-push-sideband' into maint-1.6.6
* sp/maint-push-sideband:
receive-pack: Send internal errors over side-band #2
t5401: Use a bare repository for the remote peer
receive-pack: Send hook output over side band #2
receive-pack: Wrap status reports inside side-band-64k
receive-pack: Refactor how capabilities are shown to the client
send-pack: demultiplex a sideband stream with status data
run-command: support custom fd-set in async
run-command: Allow stderr to be a caller supplied pipe
Junio C Hamano [Sun, 7 Mar 2010 20:47:17 +0000 (12:47 -0800)]
Merge branch 'gb/maint-submodule-env'
* gb/maint-submodule-env:
is_submodule_modified(): clear environment properly
submodules: ensure clean environment when operating in a submodule
shell setup: clear_local_git_env() function
rev-parse: --local-env-vars option
Refactor list of of repo-local env vars
Junio C Hamano [Sun, 7 Mar 2010 20:47:16 +0000 (12:47 -0800)]
Merge branch 'ne/pack-local-doc'
* ne/pack-local-doc:
pack-objects documentation: Fix --honor-pack-keep as well.
pack-objects documentation: reword "objects that appear in the standard input"
Documentation: pack-objects: Clarify --local's semantics.
Junio C Hamano [Sun, 7 Mar 2010 20:47:16 +0000 (12:47 -0800)]
Merge branch 'jc/fetch-param'
* jc/fetch-param:
fetch --all/--multiple: keep all the fetched branch information
builtin-fetch --all/--multi: propagate options correctly
t5521: fix and modernize
Junio C Hamano [Sun, 7 Mar 2010 20:47:15 +0000 (12:47 -0800)]
Merge branch 'nd/root-git'
* nd/root-git:
Add test for using Git at root of file system
Support working directory located at root
Move offset_1st_component() to path.c
init-db, rev-parse --git-dir: do not append redundant slash
make_absolute_path(): Do not append redundant slash
Junio C Hamano [Sun, 7 Mar 2010 20:47:14 +0000 (12:47 -0800)]
Merge branch 'mm/mkstemps-mode-for-packfiles'
* mm/mkstemps-mode-for-packfiles:
Use git_mkstemp_mode instead of plain mkstemp to create object files
git_mkstemps_mode: don't set errno to EINVAL on exit.
Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later.
git_mkstemp_mode, xmkstemp_mode: variants of gitmkstemps with mode argument.
Move gitmkstemps to path.c
Add a testcase for ACL with restrictive umask.
Junio C Hamano [Sun, 28 Feb 2010 02:56:38 +0000 (18:56 -0800)]
color: allow multiple attributes
In configuration files (and "git config --color" command line), we
supported one and only one attribute after foreground and background
color. Accept combinations of attributes, e.g.
Mark Lodato [Sun, 7 Mar 2010 16:52:45 +0000 (11:52 -0500)]
Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*
Add GIT_COLOR_BOLD_* macros to set both bold and the color in one
sequence. This saves two characters of output ("ESC [ m", minus ";")
and makes the code more readable.
Add the remaining GIT_COLOR_BG_* macros to make the list complete.
The white and black colors are not included since they look bad on most
terminals.
Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 6 Mar 2010 20:34:42 +0000 (21:34 +0100)]
revert: add --ff option to allow fast forward when cherry-picking
As "git merge" fast forwards if possible, it seems sensible to
have such a feature for "git cherry-pick" too, especially as it
could be used in git-rebase--interactive.sh.
Maybe this option could be made the default in the long run, with
another --no-ff option to disable this default behavior, but that
could make some scripts backward incompatible and/or that would
require testing if some GIT_AUTHOR_* environment variables are
set. So we don't do that for now.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3417: Add test cases for "rebase --whitespace=fix"
The command "git rebase --whitespace=fix HEAD~<N>" is supposed to
only clean up trailing whitespace, and the expectation is that it
cannot fail.
Unfortunately, if one commit adds a blank line at the end of a file
and a subsequent commit adds more non-blank lines after the blank
line, "git apply" (used indirectly by "git rebase") will fail to apply
the patch of the second commit.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: Allow blank context lines to match beyond EOF
"git apply --whitespace=fix" will not always succeed when used
on a series of patches in the following circumstances:
* One patch adds a blank line at the end of a file. (Since
--whitespace=fix is used, the blank line will *not* be added.)
* The next patch adds non-blank lines after the blank line
introduced in the first patch. That patch will not apply
because the blank line that is expected to be found at end
of the file is no longer there.
A patch series that starts by deleting lines at the end
will fail in a similar way.
Fix this problem by allowing a blank context line at the beginning
of a hunk to match if parts of it falls beyond end of the file.
We still require that at least one non-blank context line match
before the end of the file.
If the --ignore-space-change option is given (as well as the
--whitespace=fix option), blank context lines falling beyond the end
of the file will be copied unchanged to the target file (i.e. they
will have the same line terminators and extra spaces will not be
removed).
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the next commit, we will make it possible for blank context
lines to match beyond the end of the file. That means that a hunk
with a preimage that has more lines than present in the file may
be possible to successfully apply. Therefore, we must remove
the quick rejection test in find_pos().
find_pos() will already work correctly without the quick
rejection test, but that might not be obvious. Therefore,
comment the test for handling out-of-range line numbers in
find_pos() and cast the "line" variable to the same (unsigned)
type as img->nr.
What are performance implications of removing the quick
rejection test?
It can only help "git apply" to reject a patch faster. For example,
if I have a file with one million lines and a patch that removes
slightly more than 50 percent of the lines and try to apply that
patch twice, the second attempt will fail slightly faster
with the test than without (based on actual measurements).
However, there is the pathological case of a patch with many
more context lines than the default three, and applying that patch
using "git apply -C1". Without the rejection test, the running
time will be roughly proportional to the number of context lines
times the size of the file. That could be handled by writing
a more complicated rejection test (it would have to count the
number of blanks at the end of the preimage), but I don't find
that worth doing until there is a real-world use case that
would benfit from it.
It would be possible to keep the quick rejection test if
--whitespace=fix is not given, but I don't like that from
a testing point of view.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
projects / git.git / log