[PATCH 2/5] apply: read in the index in --intent-to-add mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



There are three main modes of operation for apply: applying only to the
worktree, applying to the worktree and index (--index), and applying
only to the index (--cached).

The --intent-to-add flag modifies the first of these modes, applying
only to the worktree, in a way which touches the index, because
intents to add are special index entries. However, it has not ever
worked correctly in any but the most trivial (empty repository)
cases, because the index was never read in (in apply, this is done
in read_apply_cache()) before writing to it.

If we merely gate read_apply_cache() behind update_index, then it will
not be read when state->apply is false, even if it must be checked.
Therefore, we instead read the index if it will be either checked or
updated, because reading the index is a prerequisite to either.

Reported-by: Ryan Hodges <rhodges@xxxxxxxxx>
Original-patch-by: Johannes Altmanninger <aclopte@xxxxxxxxx>
Signed-off-by: Raymond E. Pasco <ray@xxxxxxxxxxxx>
---
 apply.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/apply.c b/apply.c
index e7856ae6b3..1757d34618 100644
--- a/apply.c
+++ b/apply.c
@@ -4837,7 +4837,7 @@ static int apply_patch(struct apply_state *state,
 					       LOCK_DIE_ON_ERROR);
 	}
 
-	if (state->check_index && read_apply_cache(state) < 0) {
+	if ((state->check_index || state->update_index) && read_apply_cache(state) < 0) {
 		error(_("unable to read index file"));
 		res = -128;
 		goto end;
-- 
2.50.0.195.g74e6fc65d0





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux