From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, phiggins@google.com, snoksrud@gmail.com
Subject: Re: [PATCH 4/8] apply: make sure check_preimage() does not leave empty file on error
Date: Tue, 25 Aug 2015 10:16:09 -0700 [thread overview]
Message-ID: <xmqqd1yb1e7a.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1440205700-19749-5-git-send-email-pclouds@gmail.com> ("Nguyễn Thái Ngọc Duy"'s message of "Sat, 22 Aug 2015 08:08:07 +0700")
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> The test case probably describes the test scenario the best. We have a
> patch to modify some file but the base file is gone. Because
> check_preimage() finds an index entry with the same old_name, it tries
> to restore the on-disk base file with cached content with
> checkout_target() and move on.
>
> If this old_name is i-t-a, before this patch "apply -3" will call
> checkout_target() which will write an empty file (i-t-a entries always
> have "empty blob" SHA-1), then it'll fail at verify_index_match()
> (i-t-a entries are always "modified") and the operation is aborted.
>
> This empty file should not be created. Compare to the case where
> old_name does not exist in index, "apply -3" fails with a different
> error message "...: does not exist" but it does not touch
> worktree. This patch makes sure the same happens to i-t-a entries.
This part (unlike 3/8) is very well explained, and makes sense to
me.
> load_current() shares the same code pattern (look up an index entry,
> if on-disk version is not found, restore using the cached
> version).
The "fall-back to the cached one" is very much deliberate to allow
us to work with an empty working tree as long as the index is
correct, so this perhaps makes sense. If the user said "add -N F",
and F is involved in the patch application, we do not want to
consider F exists in the index and we would instead want to pretend
that we do not have F ourselves. It does not even make sense to do
"apply -3" for such a path, and rejecting with "does not exist" is a
good thing to do.
Good.
> Fix it too (even though it's not exercised in any test case)
Hmm, as this is adding new test for the other case, perhaps this
case is covered by another one, too?
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> builtin/apply.c | 4 ++--
> t/t2203-add-intent.sh | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 76b58a1..b185c97 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -3348,7 +3348,7 @@ static int load_current(struct image *image, struct patch *patch)
> die("BUG: patch to %s is not a creation", patch->old_name);
>
> pos = cache_name_pos(name, strlen(name));
> - if (pos < 0)
> + if (pos < 0 || ce_intent_to_add(active_cache[pos]))
> return error(_("%s: does not exist in index"), name);
> ce = active_cache[pos];
> if (lstat(name, &st)) {
> @@ -3501,7 +3501,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
>
> if (check_index && !previous) {
> int pos = cache_name_pos(old_name, strlen(old_name));
> - if (pos < 0) {
> + if (pos < 0 || ce_intent_to_add(active_cache[pos])) {
> if (patch->is_new < 0)
> goto is_new;
> return error(_("%s: does not exist in index"), old_name);
> diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
> index bb5ef2b..96c8755 100755
> --- a/t/t2203-add-intent.sh
> +++ b/t/t2203-add-intent.sh
> @@ -95,5 +95,21 @@ test_expect_success 'apply adds new file on i-t-a entry' '
> )
> '
>
> +test_expect_success 'apply:check_preimage() not creating empty file' '
> + git init check-preimage &&
> + (
> + cd check-preimage &&
> + echo oldcontent >newfile &&
> + git add newfile &&
> + echo newcontent >newfile &&
> + git diff >patch &&
> + rm .git/index &&
> + git add -N newfile &&
> + rm newfile &&
> + test_must_fail git apply -3 patch &&
> + ! test -f newfile
> + )
> +'
> +
> test_done
next prev parent reply other threads:[~2015-08-25 17:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 14:29 apply --cached --whitespace=fix now failing on items added with "add -N" Patrick Higgins
2015-06-22 14:45 ` Duy Nguyen
2015-06-22 17:06 ` Junio C Hamano
2015-06-23 12:34 ` [PATCH] apply: fix adding new files on i-t-a entries Nguyễn Thái Ngọc Duy
2015-06-23 16:50 ` Junio C Hamano
2015-06-23 17:37 ` Junio C Hamano
2015-06-24 4:48 ` Junio C Hamano
2015-06-24 10:11 ` Duy Nguyen
2015-06-24 17:05 ` Junio C Hamano
2015-06-25 12:26 ` Duy Nguyen
2015-06-25 13:07 ` Junio C Hamano
2015-08-22 1:08 ` [PATCH 0/8] Resurrect "diff-lib.c: adjust position of i-t-a entries in diff" Nguyễn Thái Ngọc Duy
2015-08-22 1:08 ` [PATCH 1/8] blame: remove obsolete comment Nguyễn Thái Ngọc Duy
2015-08-22 1:08 ` [PATCH 2/8] Add and use convenient macro ce_intent_to_add() Nguyễn Thái Ngọc Duy
2015-08-22 1:08 ` [PATCH 3/8] apply: fix adding new files on i-t-a entries Nguyễn Thái Ngọc Duy
2015-08-25 17:01 ` Junio C Hamano
2015-08-22 1:08 ` [PATCH 4/8] apply: make sure check_preimage() does not leave empty file on error Nguyễn Thái Ngọc Duy
2015-08-25 17:16 ` Junio C Hamano [this message]
2015-08-22 1:08 ` [PATCH 5/8] checkout(-index): do not checkout i-t-a entries Nguyễn Thái Ngọc Duy
2015-08-25 17:36 ` Junio C Hamano
2015-11-29 15:31 ` Duy Nguyen
2015-11-30 19:17 ` Junio C Hamano
2015-08-22 1:08 ` [PATCH 6/8] grep: make it clear i-t-a entries are ignored Nguyễn Thái Ngọc Duy
2015-08-22 1:11 ` [PATCH 7/8] diff.h: extend "flags" field to 64 bits because we're out of bits Nguyễn Thái Ngọc Duy
2015-08-25 17:39 ` Junio C Hamano
2015-08-31 10:22 ` Duy Nguyen
2015-08-25 17:37 ` [PATCH 6/8] grep: make it clear i-t-a entries are ignored Junio C Hamano
2015-08-25 17:37 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqd1yb1e7a.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=phiggins@google.com \
--cc=snoksrud@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.